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Abstract 

^  Information  overload  has  long  been  a  problem  in  the  fast  moving  technical  field  of 
software  development.  Yet  quality  information  is  needed  to  make  informed  decisions 
about  buying  software  tools  that  help  in  software  development.  Computer  Aided 
Software  Engineering  (CASE)  tools  help  to  coordinate  and  control  information  in  large 
software  developments.  Many  CASE  tool  purchases,  however,  are  being  based  on  ad 
hoc  tool  evaluation  and  selection  methods  which  depend  on  biased  vendor  information. 
To  capture  specific  knowledge  about  how  to  pick  a  tool  for  a  given  software  development 
effort,  a  historical  database  that  identifies  important  tool  characteristics  needed  to  be 
maintained  by  an  unbiased  organization  and  a  mechanism  (in  the  form  of  a  decision 
support  system)  for  interpreting  that  database  needed  to  be  made  available. 

To  address  this  deficiency,  the  Software  Technology  Support  Center  at  Hill  AFB  in 
Utah  was  developing  a  CASE  tool  selection  support  tool,  the  STEMdB,  This  re.search 
accompli.;hes  an  analysis  of  this  tool  and  suggests  ways  to  make  it  more  robust,  ponablc 
and  maintainable.  It  presents  an  object  oriented  approach  to  the  design  while  addressing 
the  issue  of  portability  by  accomplishing  an  Ada  to  Structured  Query  Language  (SQL) 
abstract  interface  design. 


ANALYSIS  OF  A  DECISION  SUPPORT  SYSTEM 
FOR  CASE  TOOL  SELECTION 
AND 

THE  SPECIFICATION  OF 
AN  ADA  TO  SQL  ABSTRACT  INTERFACE 


/.  Introduction 


Overview 

This  research  was  directed  at  comparing  two  known  CASE  tool  evaluation  and 
selection  prototypes  to  be  able  to  influence  the  ongoing  prototype  effort  towards 
developing  a  more  maintainable  and  upgradeable  decision  support  tool.  The  first 
prototype  tool  was  developed  based  on  object  oriented  methodology,  the  second  ongoing 
prototype  is  being  developed  using  the  functional  decomposition  method.  The  research 
also  provides  a  suggested  abstract  interface  design  that  would  be  used  by  the  system  to 
communicate  with  an  Structured  Query  Language  (SQL)  database. 

Background 

When  computers  were  first  developed  the  engineering  community  had  its  hands  full 
trying  to  optimize  computer  hardware  to  reduce  high  costs.  Computers  were  so 
expensive  and  huge  in  the  days  of  relay  and  vacuum  tube  technology,  that  engineers 
would  never  have  been  able  to  visualize  the  1990  desk  top  personal  computer.  With  this 
new,  smaller  more  powerful  technology,  the  costs  of  hardware  became  insignificant 
compared  to  its  counterpan,  software. 

Engineers  were  forced  to  standardize  the  development  approach  to  hardware  as  a 
result  of  those  initial  high  costs.  They  neglected  developing  just  such  an  approach  for 
software  development,  since  it  was  considered  more  an  an  than  a  science  from  their 
view-point.  As  a  result,  software  was  approached  in  an  ad  hoc  way  until  the  Siniciurcd 
Design  (SD)  Mcth(xlology  surfaced.  Once  this  methodology  surfaced  and  was 
implemented  more  complicated,  larger  .software  effons  could  be  undenaken  with  more 


1 


success.  But  as  these  efforts  got  larger,  the  SD  methodology  alone  was  not  enough  to 
ensure  that  software  systems  could  be  developed  and  implemented  on  time  and  within 
budget.  This  lack  of  control  of  software  cost  (which  is  the  critical  cost  driver  in  today’s 
systems)  and  software  quality,  resulted  in  what  scholars  of  the  I980’s  referred  to  as  the 
software  crisis  [21:389]. 

This  is  where  Computer  Aided  Software  Engineering  (CASE)  tools  entered  into  the 
equation.  Many  in  the  software  engineering  community  viewed  these  tools  initially  as  a 
solution  to  the  crisis.  However,  full  understanding  of  the  necessity  of  having  a  well 
understood  software  process  model  is  a  prerequisite  to  the  purchasing  of  any  CASE  tool 
[20:41-44;  27:9].  It  is  also  beneficial  to  have  a  general  undemanding  of  different 
software  engineering  environments  and  how  CASE  tools  fit  into  these  environments. 
Once  ail  this  has  been  accomplished,  software  professionals  can  select  a  CASE  tool,  a 
disjoint  set  of  CASE  tools,  or  an  integrated  development  environment  that  supports 
project  needs.  In  order  to  make  the  best  choice  of  development  tools,  a  survey  of 
available  tools  and  their  capabilities  must  be  requested  and  reviewed.  Unfortunately,  the 
volume  of  data  available  on  the  different  capabilities  of  tools  is  both  subjective  and 
overwhelming.  Efforts  have  been  made  in  two  complementary  prototype  tools,  the 
Software  Tool  Evaluation  Model  (STEM)  [27:6-8]  and  the  Ada  Software  Selection 
asslSTant  (ASSIST)  [24],  to  automate  this  selection  proce.ss.  It  is  at  this  point  where  this 
thesis  comes  in. 

Problem 

There  is  no  way  of  .selecting  CASE  t(X)ls  or,  in  the  bigger  sense,  software  .suppon 
cnvinMimcnLs,  without  extensive  research  of  very  subjective  data.  The  human  ability  to 
process  data  effectively  is  taxed  beyond  its  capabilities  when  juggling  more  than  alxHit 
seven  plus  or  minus  two  pieces  of  information  at  one  time.  One  C'ASE  t<x»l  ahme  can 
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have  close  to  100  different  capabilities  that  must  be  evaluated  [18;C.2-C.5].  Since 
humans  are  incapable  of  evaluating  this  much  data,  an  automated  evaluation  system,  that 
would  scale  the  selection  problem  down,  needs  to  be  developed.  At  the  time  of  this 
research,  this  researcher  was  not  aware  of  any  existing  automation  system  that  was  able 
to  implement  evaluatic»i  criteria,  take  into  account  users’  selection  requirements,  and 
propose  solution  tools. 

The  Software  Technology  Support  Center  (STSC)  at  Hill  AFB,  understood  this 
problem  and  was  developing  the  STEM  prototype  [27].  Although  the  developers  of  the 
STEM  had  not  completely  implemented  the  selection  part  of  the  prototype  at  the  time  of 
this  research,  what  was  there  appeared  to  be  tailored  more  to  individual  CASE  tool 
selection  than  CASE  environment  selections.  With  the  trend  in  CASE  tools  heading 
down  the  CASE  environment  path,  the  STEM  may  steer  the  CASE  selection  tool  effort 
towards  an  obsolete  end  requirement. 

The  ASSIST  prototype,  however,  is  set  up  as  a  theoretical  environment  evaluator 
with  the  capability  to  look  at  sub-components  of  a  total  environment.  Although  targeted 
for  Ada  tools  and  environments,  its  principles  arc  applicable  to  CASE  tools  in  general. 

Research  Objectives 

The  objective  of  this  research  was  to  provide  an  analysis  of  an  ongoing  Decision 
Suppon  System  (DSS)  design  that  would  help  guide  the  facilitators  to  develop  a  more 
substantial  tool  to  meet  future  maintainability  and  upgradcability  requirements.  The 
potential  for  the  STEM  tool  and  its  follow-on  effort,  the  STEM  Database  (STEMdB) 
t(X)l,  to  become  highly  sought  after  and  used  tools  depends  on  their  ponability  and 
flexibility.  This  research  provides  ways  to  achieve  this  portability  and  flexibility. 
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Assumptions 


The  initial  research  assumptions  were: 

-  CASE  tool  decision  support  selection  systems  are  badly  needed  in  government 
and  industry,  and  will  continue  to  be  needed  for  some  time. 

-  The  ASSIST  theoretical  architecture  would  provide  a  good  basis  for 
comparing  the  STEMdB  tool’s  functionality. 

-  Providing  both  an  object  OTiented  approach  and  an  abstract  interface  approach 
to  the  developing  organization  would  help  to  convince  them  to  design  the  STEM^  using 
these  approaches  versus  using  a  functional  design  which  was  totally  dependent  on  a 
single  database. 

-  The  underlying  structures  of  an  ASSIST  and  the  STEM  data  representation 
could  be  made  compatible. 

-  The  SQL  Ada  Module  Extensions  (SAME)  was  designed  using  good  software 
engineering  principles  so  it  was  a  good  Ada  to  SQL  binding  method  to  choose. 

-  A  STEMdB  developed  with  the  end  goal  of  supporting  remote  users  would 
force  its  design  to  be  more  robust,  if  it  was  designed  using  good  software  engineering 
principles. 

-  Providing  a  top  level  interface  design  would  help  convince  the  developing 
organization  to  approach  the  STEMdB  design  from  a  remote  user  requirements 
perspective. 

-  Providing  a  top  level  object  oriented  design  approach  to  the  STEMdB  would 
help  to  convince  the  organization  of  it’s  merits  and  would  help  them  to  understand  how  to 
work  with  the  STEMdB  as  a  DSS  that  depends  on  a  Knowledge  Base. 


Scope 

The  research  analysis  only  concentrated  on  the  portions  of  the  software  development 
life  cycle  domains  that  were  targeted  by  the  STSC.  This  researcher  accomplished  an 
analysis  of  the  STEMdB  design  from  the  data  object  and  behavioral  perspectives.  This 
researcher  al.so  accomplished  a  top  level  object  oriented  design  of  the  STEMdB  while 
providing  inforni.tf'on  on  how  to  work  with  a  knowledge  base.  Finally,  this  researcher 
accomplished  a  top  level  abstract  interface  design  using  the  SAME  method.  The 
applications  that  call  the  interface  resources  were  not  provided. 
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Approach 

First  an  extensive  literature  search  was  accomplished  to  get  a  background  on 
decision  support  systems,  CASE  tool  categmzation,  CASE  evaluation  and  selection 
criteria,  database  modeling,  Ada  to  SQL  bindings,  and  the  Macintosh  development 
environment.  In  Chapter  III  all  this  knowledge  is  used  to  evaluate  both  a  working 
prototype  and  a  proposed  follow-on  prototype  effort.  Chapter  IV  addresses  solutions  to 
two  related  problems  with  the  STEMdB  design  that  were  identified  in  the  analysis.  In 
particular,  it  presents  an  object  oriented  design  and  an  abstract  interface  design.  Finally 
Chapter  V  concludes  with  lessons  learned. 


5 


//.  Literature  Review 


Introduction 

The  following  literature  review  was  accomplished  to  learn  about  CASE  tools, 
Software  engineering  environments,  CASE  evaluation  and  selection  processes,  CASE 
selection  system  design.  Entity  Relationship  modeling  and  a  Macintosh  development 
environment. 

Specifically,  the  literature  gave  insight  into  reasons  an  organization  would  purchase 
CASE  tools,  and  identified  different  ways  to  categorize  CASE  tools.  Some  articles 
discussed  the  pitfalls  of  CASE  while  others  addressed  the  different  levels  of  tool 
integration.  The  Entity  Relation  diagramming,  and  the  Decision  Support  tool  studies 
helped  with  analyzing  the  STEMdB  design  and  suggesting  improvements.  The 
Macintosh  HyperCard  development  environment  literature  also  provided  insights  into 
how  the  ASSIST  prototype  accomplished  its  job  and  into  how  a  commercial  database, 
Oracle,  provided  a  programming  interface  to  its  database. 

CASE  Tools,  Why  Bother? 

Brook’s  book,  [  1 2],  as  well  as  Batt  and  Sims  in  [  1 0: 1 ;  28: 1  ]  discussed  different 
aspects  of  the  software  crisis.  Both  Batt  and  Sims  theses  [10;  28]  u.sed  the  perceived 
crisis  as  Justification  for  studying  CASE  technology  as  a  possible  solution  to  the  crisis. 
Other  literature  also  eluded  to  aspects  of  the  software  crisis  as  reason  to  study  the 
possible  benefits  of  CASE  in  .software  development. 

Software  tool  automation  could  facilitate  consi.siency  checking,  automatic 
documentation  of  design,  configuration  management  of  code,  overall  project  tracking, 
design  generation,  the  enforcement  of  formalisms  and  structured  methodologies  [26:75], 
and  design  accessibility  (via  t(X)ls  that  u.sc  relational  database  queries  or  Hypertext 
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[1 1:23])  according  to  general  consensus.  Hypertext  was  defined  by  Bigelow  in  [1 1 :23] 
as : 

Hypertext  is  a  medium-grained,  entity-relationship  model  that  lets 
information  be  structured  arbitrarily  and  keeps  a  complete  version  history  of 
both  information  and  structure.  [11 :23] 

CASE  Categories 

CASE  tools  were  categorized  by  different  authors  in  distinct  ways.  Tamanaha 
viewed  CASE  tool  categories  as  falling  within  some  phase  of  the  Waterfall  software  life 
cycle  model,  as  falling  within  a  narrow  discipline  like  documentation,  or  as  falling  into  a 
specific  application  domain  like  real-time  systems  [29:6].  She  identifies  five  phases 
associated  with  the  Waterfall  model:  requirements/analysis,  design,  code,  test  and 
maintenance. 

Sim’s  took  a  much  higher  level  approach  than  Tamanaha.  He  viewed  CASE 
tools  as  falling  in  four  categories:  Upper-CASE,  Lower-CASE,  Reverse 
Engineering/maintenance-CASE  and  Project  Management-CASE.  The  Upper-CASE 
tools  applied  to  the  life  cycle  phases  requirements  through  design;  the  Lower-CASE 
applied  to  code  through  test;  the  Reverse  Engineering/maintenance-CASE  applied  to  the 
end  of  the  life  cycle  after  test;  the  Project  Management-CASE  applied  to  all  phases  of  the 
life  cycle  [28:33-34].  Sim’s  also  reported  survey  re.sults  which  highlighted  Upper-CASE 
tools  as  being  the  most  u.sed,  75%  usage  in  industry  during  1 988  versus  less  than  20% 
usage  in  any  other  of  his  categories  [28:72]. 

CASE  Pitfalls 

In  both  [22:25-29;  20:41-44]  the  reader  was  warned  about  potential  pitfalls  that 
could  occur  while  attempting  to  begin  and  to  continue  using  CASE  technology.  Not 
understanding  an  organization’s  software  pr(x:c,ss  model  was  one  pitfall  that  was 
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repeatedly  acknowledged  in  different  literaiyre.  Keuffel  reinforces  this  by  ending  his 

article  with  this  quote  about  the  software  methods: 

“CASE  systems,”  DeMarco  concluded,  “have  tended  to  be  most  helpful  to 
people  who  had  the  least  trouble  applying  the  method,  even  without 
automated  support.”  [22:29] 

Another  identified  pitfall  was  the  fact  that  vendors  were  producing  volumes  of  subjective 
material  about  the  sanctity  of  their  products  [22:25].  Keuffel  in  [22:29]  stated  that 
“current  CASE  tools  either  ignore  many  rules  or  enforce  them  too  rigidly”.  He  advocated 
making  tools  “transparent”  to  the  users  [22:28]  in  order  to  support  user  friendliness. 

CASE  Tool  Integration 

Different  levels  of  CASE  tool  integration  were  aiso  a  common  topic  in  the  literature. 
According  to  Keuffel,  the  highest  achievable  level  of  integration  was  achievable  through 
“Groupware”  [22:29].  Groupware  is  a  real-time  re.spon.se  CASE  system  that  could 
become  a  design  group’s  intelligent  whiteboard. 

Batt,  in  [10:13],  introduced  the  term  I-CASE.  He  defined  this  term  as,  “I-CASE 
toolkits  incorporate  all  the  be.st  features  of  many  CASE  t(X)ls  into  a  single  package  that  is 
intended  to  cover  the  entire  SDLC”  [  10: 1 3]  (where  SDLC  stands  for  software 
development  life  cycle).  Batt  stated  that  a  true  I-CASE  tool  would  incorporate  over  1(X) 
sub-Ux)ls  and  that  no  true  1-CASE  tool  existed  at  that  time.  The  term  I-CASE  can  be 
thought  of  conceptually  as  the  ideal  software  development  environment  where  all  t(X)ls 
inter-operate  and  share  common  data. 

The  term.  Data  Encyclopedia,  was  introduced  and  defined  by  Batt  as  “The  heart  of 
an  I-CASE  toolkit."  1 10:13].  In  other  environment  contexts  it  was  called  the  object 
management  .system.  The  Data  Encyclopedia's  counterpart  in  the  non-integrated  CASE 
world  was  the  equivalent  of  the  Data  Dictionary.  Batt  indirectly  addressed  at  least  four 
levels  of  CASE  integration  in  his  thesis.  Those  levels  were:  no  integration,  limited 
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integration  in  one  CASE  tool  line,  some  integration  outside  of  one  product  line  and  total 
integiation.  The  integration  literature,  in  general,  agreed  that  higher  levels  of  CASE 
integration  could  be  achieved  from  industry  support  of  open  CASE  architectures  and 
CASE  tool  interface  standards. 


Software  Engineering  Environments 

Wybolt  in  [30:57]  provides  a  good  overview  of  the  requirements/attributes  of 
Integrated  Project  Support  Environments  (DPSE’s).  He  lists  the  following  as  desirable 
characteristics  of  an  IPSE  [30:57]: 

•  cover  all  phases  of  development  and  support 

•  support  or  connect  with  multiple  disciplines  like  CAD  or  CAE 

•  cover  many  project  activities  such  as  planning,  contfolling 
and  documentation 

•  deal  with  multiple  vendors  and  platforms 

•  adapt  to  existing  organizational  culture  and  work  flows 

•  can  be  introduced  incrementally 

•  can  be  serviced  and  supported 

•  are  fast  and  inexpensive 

Wybolt  also  clarifyed  how  a  framework  was  the  building  block  of  IPSE’s.  He 
defined  the  structure  of  a  framework  as  having  a  common  user  interface,  a  set  of  tools,  an 
integrating  agent,  and  an  object  management  system.  He  defined  the  four  styles  of 
integration  that  could  be  implemented  within  a  framework  as:  presentation,  control,  data 
and  semantics.  Presentation  integration  was  provided  through  a  common  user  interface; 
data  integration  among  tools  was  provided  through  a  common  repository;  control 
integration  was  provided  through  repositories  with  links  between  them;  and  semantic 
integration  was  provided  through  modeling  of  the  semantics  of  t(X)ls  and  their  data  along 
with  conflict  reconciliation.  [30:56-591 

Finally,  Wybolt  clarified  that  ‘’integration  is  a  property  of  a  relationship  between  two 
or  more  tools”  [30:59]  not  a  property  of  an  environment  or  t(X)l. 
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CASE  Evaluation  and  Selection  Guidelines 

The  draft  document  in  [1]  provided  soiiie  guidance  on  the  process  of  evaluation  and 
selection  of  CASE  tools  that  support  the  software  project  management,  configuration 
management,  and  software  engineering  domains.  To  clarify  the  difference  between  the 
two  processes,  evaluation  is  “the  process  of  measurement”  and  recording  while  selection 
is  “the  process  of  applying  thresholds  and  weights  to  evaluation  results  and  arriving  at 
decisions”  [1].  The  BEEE  document  in  [1]  also  emphasized  the  iterative  nature  of  these 
two  processes  and  the  necessity  for  feedback  from  the  selection  process.  Feedback  was 
to  take  the  form  of  user  critiiiues  of  any  selection  and  evaluation  system  that  was  being 
used.  Without  this  feedback  neither  process  could  become  a  mature  process.  Criteria  that 
are  measured  both  quantitatively  and  qualitatively  are  the  common  link  between  the  two 
processes.  [1]  defined  users  requirements  as  the  only  driving  force  towards  deciding  on 
these  criteria  and  suggested  several  possible  classification  schemes,  including  the  E&V 
Reference  manual  (2]. 

An  evaluation  process  should  address  tool  issues  of  multi-project  suppon  and 
multi-function  support.  In  other  words  it  should  provide  for  an  evaluation  w'hich 
measures  tools  that  are  abstract  enough  to  address  both  the  immediate  project  functional 
needs  of  the  user  as  well  as  any  future  new  project  requirements.  It  should  be  repeatable 
for  the  objective  criteria  and  it  should  accommodate  documentation  of  multiple  evaluator 
inputs  for  the  .subjective  criteria.  ( 1  ] 

A  selection  prtxess  should  allow  for  a  narrowing  down  of  information.  The  reasons 
for  steps  taken  during  the  selection  procc.ss  .should  be  recorded.  .Since  .selection  criteria 
will  be  either  numeric  or  binary,  a  way  of  weighing  and  combining  both  types  must  be 
addressed.  Traceability  of  the  feedback  loop  to  the  evaluator  process  must  be  addressed. 
If  the  evaluator  prtKess  never  receives  feedback  from  the  users  or  rcx)l  selectors,  then  the 
evaluator  works  in  a  vacuum  and  the  whole  evaluation  and  selection  piXK'css  nins  the  risk 
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of  being  useless.  Finally,  a  sensitivity  analysis  should  be  supported.  Sensitivity  must  be 
addressed  so  that  selector  or  user  is  able  to  judge  how  valid  his  /her  results  were  based  on 
the  limitations  of  the  system.  [1] 

The  workshop  notes  in  [3]  discussed  pre-selection  proces  s  strategy  considerations 
that  need  to  be  considered  prior  to  an  organization  entering  into  the  CASE  tool  selection 
process. 

CASE  Selection  System  Design 

The  Lawlis  dissertation  provides  guidelines  on  how  to  .:se  the  above  evaluation  and 
selection  techniques,  as  well  as  other  design  criteria  to  create  an  automated  decision 
support  system  for  CASE  tool  selection. 

The  basic  processing  in  her  design  began  with  the  nairowing  down  of  candidate 
tools.  She  assessed  three  levels  with  respect  to  the  user’s  needs:  the  scope/context  of  the 
solution  space,  the  tool  category,  and  the  application  area.  Once  these  were  input  her  tool 
requested  the  specific  weights  of  applicable  characteristics.  Finally  the  ASSIST  would 
process  the  inputs  and  provide  some  suggested  solutions. 

The  basic  structure  of  systems  that  support  this  design  would  be  composed  of  four 
top  level  objects  as  is  shown  in  Figure  1 . 

The  Knowledge  Acquisition  object  allows  users  to  load  and  update  data  stored  in 
both  the  Knowledge  Base  and  the  Database.  The  user  could  access  the  Knowledge  Base 
and  the  Database  indirectly  through  both  this  object  and  the  Decision  Logic  object. 

The  Knowledge  Base  object  provides  the  operations  necessary  to  use  the  data.  It 
could  accomplish  these  tasks  because  it  maintained  the  design  knowledge  on  how  the 
data  was  stnictured.  In  addition,  it  could  control  how  a  selector  used  that  data. 

According  to  (24:70]  a  critical  part  of  the  design  of  a  DSS  is  the  isolation  of  its 
dynamic  elements  and  operations  to  the  Knowledge  Base  Subsystem.  Specifically,  the 
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Knowledge  Base  Subsystem  should  define  which  software  characteristics  are  made 
visible  to  the  rest  of  the  DSS.  It  should  know  the  types  and  the  allowable  operations  on 
all  characteristics  and  it  should  provide  this  knowledge  to  the  rest  of  the  system.  Since 
leveling  of  information  is  necessary  to  make  a  selection  tool  effective,  the  Knowledge 
Base  Subsystem  should  contain  knowledge  on  levels  of  views  and  it  should  provide  the 
information  on  how  to  process  these  levels  to  the  rest  of  the  system.  Finally  a  Knowledge 
Base  Subsystem  should  contain  the  knowledge  of  how  to  transform  evaluation  data  into 
ratings.  By  concentrating  all  of  these  volatile  design  areas,  a  DSS  design  maintains 
robustness  and  ensures  that  most  future  revisions  affect  only  the  implementation  part  of 
the  DSS  Knowledge  Base  object. 

One  concept  of  this  design  that  was  hard  to  comprehend  was  understanding  the 
difference  between  a  Knowledge  Base  and  a  Database.  It  was  discovered  that  the 
differences  between  a  database  system  and  a  knowledge  base  system  could  be 
distinguished  by  the  kind  of  data  stored  in  each  and  the  operations  provided  by  each.  For 
example,  a  database  system  would  provide  the  services  of  storage  and  retrieval  of  all 
evaluation/selection  data.  A  knowledge  base  system  would  provide  for  the  interpretation 
of  that  data. 

The  Decision  Logic  Object  is  the  controller  of  the  Decision  .Support  System 
processes.  Essentially,  it  addressed  requirements  that  were  based  on  a  user  that  was  in 
the  process  of  selection. 

Entity  Relationship  Diagrams 

A  quick  explanation  of  an  Entity  Relationship  diagram  and  how  it  relates  to  the  table 
relational  design  is  provided  next,  so  that  readers  will  have  the  proper  background  to 
understand  the  work  accomplished  in  Chapter  III.  Entities  arc  objects  that  exist  and 
which  have  specific  descriptive  attributes  that  distinguish  them  from  one  another.  For 
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instance  a  mother  and  a  child  are  two  entities  which  both  have  an  attribute  of  social 
security  number,  but  the  value  of  those  attributes  differs  for  each  of  them.  A  relationship 
is  a  connection  between  two  or  more  entities.  For  instance  two  relationships,  has_child 
and  has_genetic_child,  between  a  mother  and  her  five  children  would  contain  the  names 
of  all  five  children  in  the  first  relationship  and  would  contain  the  name  of  only  one  child 
in  the  second  relationship  if  the  mother  had  adopted  four  of  her  five  children. 


Figure  1 .  Decision  Support  Sy.stem  Top  Level  Design|24;291  ] 
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Entity  Relationship  models  provide  several  different  pieces  of  information.  They 
provide  entity  and  relationship  definitions  in  the  form  of  named  rectangles  and  named 
diamonds,  respectively.  They  display  all  important  attributes  (distihguishing  key 
attributes  with  bold  capital  letters),  and  they  display  the  cardinality 'and  optionality  (these 
are  explained  in  the  next  paragraph)  between  entities  and  relationships.  They  also 
support  the  notion  of  abstraction  by  the  concept  of  an  aggregate.  In  simple  terms  an 
aggregate  is  a  means  of  showing  a  n-way  relationship  (where  “n”  is  the  number  of  related 
entities).  In  structural  terms  an  aggregate  is  a  super  entity  that  encloses  two  or  more 
related  entities  and  acquires  the  key  attributes  of  those  related  entities. 

Cardinality  and  optionality  are  constraints  that  the  design  of  an  actual  database 
implementation  would  maintain  [23:28].  Cardinality  is  just  a  mapping  function  between 
two  related  entities.  For  instance,  the  cardinality  could  define  that  exactly  one  of  each 
entity  relate  to  one  of  another  (a  one  to  one  function)  or  it  could  define  a  one  to  many,  a 
many  to  many,  or  a  many  to  one  relationship.  Optionality  shows  an  exi.stencc 
dependency  between  two  entities  over  a  relationship.  If  an  entity  has  a  mandatory 
relationship  with  another  entity,  then  the  latter  entity  will  need  to  be  altered  as  a  result  of 
a  deletion  in  the  former  entity  (in  one  to  many/many  to  one,  but  not  necessarily  in  many 
to  many).  Conceptually,  optionality  can  be  understood  by  asking  the  question,  what  is 
the  minimum  number  of  associations  that  must  hold  in  a  relationship  between  entities. 

An  existential  dependency  of  one  entity  on  another  means  that  the  dependent  entity  dcxis 
not  make  .sense  in  the  model  if  its  required  entity  relationship  no  longer  exists.  Finally, 
the  graphical  rcprc.sentation  of  optionality  and  cardinality  takes  the  following  form: 
“a:P”.  Where  a  represents  the  optionality  and  it  takes  on  values  of  cither  "O”  or  “1”  and 
P  rcprc.scnts  the  cardinality  where  it  becomes  a  letter  in  the  alphabet  to  represent  “many” 
or  it  becomes  the  number  “1”.  For  instance,  "1  :N”  means  an  entity  is  mandatory  and  that 
it  has  the  cardinality  of  “many”  in  a  relationship  with  another  entity. 
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HyperCard 

In  [2:1 1]  it  was  stated  that  HyperCard  could  be  used  to  “gather,  organize,  present, 
search,  and  customize  information”.  Design  ideas  based  on  HyperCard’s  data 
representation  were  presented  in  [1).  HyperCard  supports  external  function  calls  to 
pre-compiled  C  and  Pascal  code.  This  tool  was  used  to  create  a  user’s  tutorial  for  each  of 
the  three  prototype  tools  in  [7;  8;  9].  It  was  also  used  as  a  development  environment  for 
[24]  and  as  a  database  interface  called  Hyper*SQL  within  Oracle  [25],  HyperCard 
provides  the  user  interface  and  test  program  capability  which  reduce  the  level  of  work 
required  for  a  prototype  effort  in  the  Macintosh  environment. 

Conclusions 

CASE  tools  are  needed  to  help  in  both  large  and  small  software  projects.  The  larger 
the  communication  gap  in  a  project  the  more  severe  the  problems  become.  CASE  tools 
as  they  become  more  mature,  and  as  they  integrate  more,  should  achieve  some  positive 
impact  on  these  software  problems  by  increasing  project  data  accessibility. 

There  arc  multiple  ways  of  viewing  CASE  tool  membership  categories.  There  are 
also  several  ways  of  getting  into  trouble  with  CASE  tools.  Integration  appears  to  be 
where  the  future  of  CASE  development  is  headed. 
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III.  Description  and  Analysis  of  The  STEMdB  Prototype  Design 


Overview 

This  chapter  provides  the  reader  with  an  understanding  of  Software  Tool  Evaluation 
Model  Database  (STEMdB)  design  efforts  that  were  going  on  concurrently  with  this 
research.  It  begins  by  providing  a  descripticm  of  the  the  Software  Technology  Support 
Center’s  (STSC’s)  development  efforts  and  mission  objectives.  It  discusses  the 
background  work  that  the  STSC  had  accomplished  which  lay  the  foundation  for 
development  efforts  towards  the  STEMdB.  The  chapter  then  provides  the  reader  with  the 
objectives  of  the  STEMdB  within  a  defined  scope.  It  then  accomplishes  a  multi-level 
description  of  the  design  followed  by  an  analysis.  The  analysis  results  were  based  on  the 
knowledge  gained  from  Chapter  II.  In  particular,  the  analysis  compares  the  STEMdB 
design  to  the  knowledge  gleaned  from  (1]  and  the  ASSIST  prototype. 

Description  of  STEMdB 

Scope  and  Purpose  of  STEMdB.  Scope:  To  define  an  evaluation  framework  that 
could  be  populated  with  evaluation  information  that  would  support  the  selection  of  CASE 
tools.  Specifically,  to  support  selection  of  CASE  toots  that  would  meet  support  criteria 
over  multiple  phases  of  the  software  development  life  cycle,  different  application 
domains  and  ditTereni  subsets  of  software  engineering  activities. 

Purpose:  According  to  [  19:1 ).  'The  puiposc  of  stemDB  is  to  allow  the  systematic, 
reliable,  repeatable,  and  helpful  selection  of  CASE  uxils  for  those  in  need  of  such 
technology”. 

Background  of  STEMdB.  In  order  to  understand  the  background  of  the  STEMdB 
design  at  the  time  of  this  research,  the  historical  work  of  the  organization  that  was 
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developing  the  STEMdB  had  to  be  presented.  The  STSC  located  at  Hill  APB  in  Utah 
was  the  developing  organization.  Part  of  the  mission  of  the  STSC  was  to  provide  the  Air 
Force  with  “centralized  support  for  the  evaluation  and  selection  of  software  tools, 
methods  and  environments...”  [18:1].  To  accomplish  this  mission,  the  STSC  defined  an 
iterating  process  which  identified  both  software  problems  and  requirements  of  the  Air 
Force,  analyzed  current  software  tools  and  technologies,  and  recommended  possible 
solution  tools,  methods,  and  environments  [18:1]. 

According  to  [21:5]  “the  primary  objective”  for  any  process  should  be  “to  achieve  a 
controlled  and  measured  process  as  the  foundation  for  continued  improvements”. 
Humphrey  showed  in  [21:5]  that  the  first  step  towards  achieving  a  mature  process  at  this 
level  would  be  to  achieve  repeatability.  To  achieve  repeatability,  the  STSC  implemented 
their  newly  defined  iterating  process  within  the  framework  of  a  Test  and  Evaluation 
(T&E)  Process.  This  process  was  composed  of  area-specific  T&E  Guidelines  (TEG’s) 
that  were  used  to  evaluate  software  characteristics.  Given  a  tool,  a  software  characteristic 
and  an  area  of  interest  or  domain  as  inputs,  the  T&E  Process  would  produce  two  outputs: 
an  evaluation  result  and  a  T&E  Procedure  (TEP).  A  TEP  was  the  documentation  of  an 
evaluator’s  actions  taken  while  implementing  a  TEG.  Figure  2  illustrates  this  process. 


Characteristic 


Figure  2.  STSC  Test  and  Evaluation  Process 
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The  culmination  of  these  efforts,  at  the  time  of  this  research,  was  a  series  of 
databases  that  categorized  specific  software  characteristics  within  high-level  functional 
domains  of  software  usage  (i.e..  Test,  Documentation,  Uppercase,  Software  Engineering 
Environments  (SEE’s)).  The  STSC  defined  these  high-level  domains  as  tool  domains 
where  “Tool  domains  categorize  software  tools  by  their  major  functional  capabilities  to 
compare  similar  tools”  [18:  7].  Figure  3  gives  a  clearer  picture  of  how  to  visualize  these 
domains.  The  high-level  domain  equates  to  the  Evaluation  Framework  node  in  the  tree  of 
Figure  3.  The  rest  of  the  nodes  in  the  figure  represent  the  software  characteristics  that 
would  be  analyzed  for  a  specific  tool.  Appendix  A  provides  a  representative  STSC 
listing  of  specific  software  characteristics  and  qualities  for  the  Requirements  Analysis 
and  Design  (or  Upper  Case)  Domain  [18:66-75]. 


Figure  3.  Example  Tool  Domain  Evaluation  Framework  [18:  12) 
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As  the  reader  will  soon  realize,  all  of  this  work  helped  the  STSC  to  define  the 
specific  requirements  that  an  automated  system,  the  STEMdB,  should  be  built  to  meet. 
With  this  background  in  mind,  the  details  of  the  STEMdB  design  can  now  be  provided. 

Top  Level  Description  of  STEMdB.  In  order  to  describe  the  functional  operations  of 
the  STEMdB,  the  structural  and  functional  requirements  will  be  presented  next,  followed 
by  an  implementation  design  description. 

Representative  Requirements  Listing.  The  list  is  a  representative  rather  than 
exhaustive  list  of  key  STEMdB  requirements  as  recognized  by  this  researcher.  For  more 
details  the  reader  is  referred  to  [19]. 

1.  Build  STEMdB  tool  to  work  around  a  hierarchical  organization  of  CASE  tool 
software  characteristics. 

2.  Use  linearly  weighted  combination  of  a  tool’s  characteristics  to  arrive  at  a  scalar 
measure  for  tool  scores  [19:8]. 

3.  Use  the  identifying  concept  of  a  Softwarc  Area  of  Interest  (SAI)  to  categorize 
tools.  The  SAI  is  defined  by  a  high  level  domain,  a  target  application  or  Software 
Engineering  Activity  (SEA)  within  that  domain  and  a  life  cycle  phase.  The  STSC  defines 
a  domain  as  being  cither  “Management,  Development,  Test,  Review,  or  Product 
Support”.  The  STSC  provides  an  example  of  an  SEA  in  Management  as  being  either 
“Project  Management”  or  “Configuration  Management”.  Finally  the  STSC  defines  a  life 
cycle  phase  as  consisting  of  one  of  the  following:  “Concept,  Requirements,  Preliminary 
Design,  Detailed  Design,  Implementation  and  Unit  Test,  Integration  and  Test,  Acceptance 
and  Delivery,  or  Maintenance”.  [19.5] 

How  this  all  relates  to  the  “high-level  functional  domains  of  software  usage”  is 
defined  by  ihe  part  of  the  STEMdB  called  the  Formulator  (  a  description  of  the 
composition  of  the  STEMdB  is  presented  later  in  this  chapter). 
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4.  Compute  a  function  related  score  for  each  characteristic  in  the  data  model  using 
the  linearly  weighted  method.  Perform  a  similar  analysis  for  each  of  twelve  quality 
attributes  associated  with  the  characteristic.  Allow  the  user  to  enter  the  weights  used. 
[19:9] 

5.  Use  the  framework  of  a  General  Software  Characteristic  (GSC)  with 
instantiations  of  this  framework.  Specific  Software  Characteristic’s  (SSC’s)  containing  a 
functional  value,  a  TEP,  quality  values  and  evaluation  information  for  specific  tools.  All 
GSC’s  will  be  defined  by  the  functional/non-functional  tool  characteristic  identification 
work  being  accomplished  at  the  STSC  during  the  time  of  this  research.  A  more  detailed 
definition  of  a  GSC  will  follow  in  the  implementation  and  detail  level  design 
descriptions. 

6.  Allow  five  types  of  evaluation  answers  (Evaluate  Children,  Yes  or  No,  Multiple 
Choice,  Single  Item  Checklist,  and  Text)  within  the  characteristic  framework  [19: 12]. 

7.  Suppon  three  separate  functional  operations,  Formulation,  Evaluation  and 
Selection.  Allow  concurrent  evaluation  and  selection  operations,  but  force  the 
formulation  stage  to  a  stable  state  before  allowing  evaluations  and  selections  to  occur. 
[19:10] 

8.  Use  a  commercial  database  that  supports  Structured  Query  Language  (SQL)  to 
manipulate  and  store  the  characteristic  data.  Provide  for  a  tool  interface  that  will  issue 
SQL  commands  to  the  database  and  receive  data  from  the  database.  The  commercial 
database  must  be  able  to  suppon  up  to  2000  tool  evaluations  with  as  many  as  KXX) 
software  characteristic.s.  [  19:10, 20-23] 

9.  Front  end  programming  language  chosen  for  implementation  will  be  '’limited  to 
those  that  support  SQL  commands  with  a  particular  database”  jl  9:7.5]. 

10.  "Platform  upon  which  the  system  will  run  is  limited  to  those  that  can  host  both 
the  front  end  implementation  language  and  the  database”  1 19:75]. 
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Implementation  Design  DescHption.  Essentially  the  STEMdB  is  composed  of 
five  systems:  The  commercial  database,  the  Formulator,  the  Evaluator,  the  Selector  and  a 
user  interface  front  end.  Figure  4  shows  how  such  a  system  could  be  visualized.  The 
arrows  indicate  communication  between  components  in  the  form  of  commands. 


Conceptually,  the  data  that  describes  a  CASE  uwl’s  functionality  within  a  domain 
can  be  viewed  as  a  dc.scription  tree,  where  the  functionality  of  the  top  node  of  that  tree 
describes  the  functionality  of  the  tool.  This  concept  is  based  on  requirement  4,  where  the 
functionality  of  a  node  is  equal  to  the  weighted  sum  of  the  functionality  of  its  children. 
Each  node  in  the  description  tree  will  be  a  SSC  which  contains  the  evaluation  data 
associated  with  the  functionality  of  that  node. 
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The  database  subsystem  would  be  chosen  to  provide  both  an  SQL  interface  and  the 
full  functionality  of  a  standard  database.  A  front  end  interface  would  be  used  to 
communicate  between  the  database  and  the  other  three  subsystems. 

The  Formulator’s  principle  function  would  be  “to  specify  the  various  functional 
areas  that  describe  the  performance  of  CASE  tools  and  then  to  build  a  description  tree  for 
each  area”  [19].  The  Formulator  subsystem  must  be  able  to  build  description  trees  out  of 
a  framework  of  GSC’s.  The  GSC’s  chosen  for  the  framework  will  be  identified  as  a 
result  of  the  work  that  is  still  ongoing  at  the  STSC  under  the  T&E  Process.  The  method 
that  describes  how  to  evaluate  a  description  tree  will  be  implicitly  defined  by  the  “type” 
of  evaluation  answer  that  the  Formulator  encodes  at  each  node  in  the  tree.  The 
Formulator  needs  to  be  able  to  access  the  database  to  store  SAl  design’s. 

The  Evaluator  must  be  able  to  access  a  specific  SAI  design  in  the  database,  to 
understand  how  to  evaluate  its  description  tree  based  on  the  types  associated  at  each  GSC 
node,  and  it  must  be  able  to  store  the  evaluations  as  an  instantiation  of  the  SAI  design  for 
a  specific  tool.  Once  the  Evaluator  subsystem  evaluates  a  GSC,  it  should  be  able  to  store 
the  results  in  the  SSC  that  maps  to  that  GSC. 

The  Selector  must  be  able  to  access  tool  specific  instantiations  of  the  SAI  design.  It 
must  be  able  to  define  weights  for  every  SSC  node  in  the  design.  It  must  be  able  to  save 
these  weights  in  a  weight  set  area  of  the  database  for  the  tool  specific  instantiation.  It 
must  be  able  to  understand  how  to  score  a  tool  and  its  individual  characteristics  given 
both  an  SAI  description  tree  and  a  weight  .set.  It  must  be  able  to  save  sets  of  u.ser  defined 
tool  names. 

Detail  Level  Description  of  STEMdB.  The  next  three  .sections  present  a  de.scription 
of  the  STEMdB  design  data  .semantics,  subsystems  communications,  and  subsystem 
prtx'cssing. 
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STEMdB  Data  Model  Description.  One  of  the  best  ways  to  visualize  a  data 
model  is  through  a  graphical  illustration.  Data  models  provide  both  “data  and  structural 
information”  [19:3].  The  requirements  document  in  [19:25]  provided  the  table  relational 
diagram  shown  in  Figure  5,  but  this  illustration  did  not  provide  an  immediate  picture  of 
how  the  data  was  structured  without  extensive  study. 
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Figure  5.  STEMdB  Requirements  Table  Relational  Diagram 


To  gain  more  insight  into  how  the  data  was  structured,  the  entity  relationship  (ER) 
diagram  in  Figure  6  was  developed  from  both  general  t(X)l  usage  knowledge  and  from  the 
table  relational  diagram  of  Figure  5.  An  attempt  was  made  to  maintain  the  same  naming 
conventions  used  in  [19:25-32]  in  order  not  to  confuse  those  referring  back  to  this  STSC 


23 


requirements  document.  To  achieve  better  readability  ar  d  understandability  of  the 
design,  however,  the  following  changes  were  tnade : 

1.  Four  relational  table  names  were  changed 

-  Speciric_Soft_Char  and  General  _Soft_Char  tables  were  expanded  to  their  full 

names. 

-  Thve_Score  table  was  renamed  software_char_score 

-  The_Weight  table  was  renamed  software_char_weight 

2.  The  linking  relationships  were  provided  shoner  names  that  all  began  with  “link” 
and  ended  in  two  capital  letters  that  matched  the  first  distinguishing  letter  of  each  linked 
table.  For  instance  linkAT  connected  the  The_Tool  table  to  the  The_Area  table.  There 
were  two  cases  where  this  rule  was  broken.  The  first  case  involves  all  non-trivial 
relationships  (relationships  that  contained  attributes  in  excess  of  the  mandatory  keys)  of 
linked  entities.  All  non-trivial  relationships  were  given  a  descriptive  relationship  name. 
The  other  case  involves  the  “root_node”  relationship.  This  relationship  needed  a  more 
descriptive  name  to  identify  it  as  linking  an  area  to  the  top  node  of  a  description  tree. 

3.  Finally,  one  linking  relation  was  added  between  The_Arca  and  The 
General_Software_Characteristic  tables.  The  root_node  link  was  added  to  clarify  the 
relationship  between  the  Area  and  a  general  software  characteristic. 

The  way  that  an  ER  model  is  converted  to  the  table  relational  form  is 
straightforward.  In  general  all  entities  and  relations  become  tables  with  their  attributes 
becoming  table  field  names  (or  column  names  in  other  words).  Distinguishing  attributes 
become  key  attributes  in  the  tables.  Each  general  characteristic,  for  example,  would  be 
designated  a  row  (or  a  record)  in  the  General_Software_Charactcristic  tabic.  To  access 
the  attributes  of  a  specific  general  characteristic,  one  would  search  for  the  unique  key, 
GCS_ID,  that  equals  the  desired  GCS_ID  key.  Relation  tables  also  inherit  as  key 
attributes  the  key  attributes  of  the  entities  that  they  connect.  If  aggregation  exists  then  the 
aggregate  inherits  attributes  of  its  internal  relationship  and  it  becomes  a  table.  For 
instance,  the  Specific  Software  Characteristic  aggregate  table  would  have  field  names  of: 
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SSC_ID,  GCSJD.  TOOL_ID,  value,  and  tep.  The  SSC_ID,  value  and  tep  were  already 
attributes  of  the  Specific  Software  Characteristic  relationship ,  it  inherited  the  TOOL_ID 
key  from  the  The_Tool  entity  and  it  inherited  the  GCS_ID  from  the  General  Software 
Characteristic  entity. 


Figure  6.  Entity  Relationship  Diagram  of  STEMdB 


2.5 


Description  of  Key  Entities  and  Relationships  of  Figure  6.  The  entities  in 
the  STEMdB  data  model  are  as  follows: 

1.  The_Tool  -  Contains  basic  tool  information  as  defined  in  the  attributes  of 
Figure  6. 

2.  The_Area  -  Functional  areas  to  which  CASE  tools  will  map.  These  areas  map  to 
the  high  level  tool  domains  discussed  earlier, 

3.  General_Software_Chardcteristic  -  Framework  which  the  STEMdB  tool  is  built 

on.  The  following  is  an  explanation  of  all  non-self  explanatory  attributes: 

formu_?  -  Is  an  explanatiwi  comment  stored  in  the  CSC  by  the  designer  of  the 
domain  description  tree.  The  comment  explains  why  the  designer  chose  to  insert  a 
particular  characteristic  at  a  particular  location  in  the  tree. 

evalu  ?  -  Is  the  evaluation  question  that  an  evaluator  must  answer  to  evaluate 
the  characteristic. 

evalu_help  -  Explains  the  justification  for  addressing  the  evaluation  question  of 
a  characteristicr 

essential_flag  -  Maps  back  to  the  STSC  “shon  tool  list”  concept.  In  [27]  a  shon 
tool  list  was  the  lisT of  tools  that  met  the  minimum  Air  Force  Requirements  as  determined 
by  the  STSC.  In  the  context  of  the  STEMdB,  the  Formulator  tool  flags  a  characteristic 
as  essential  when  it  must  be  evaluated  favorably  for  the  tool  to  be  considered  in  a 
selection. 


evalu^method  -  This  is  a  Boolean  variable  that  lets  the  evaluation  tool  know 
whether  or  not  this  characteristic  must  be  evaluated.  When  a  characteristic  contains  the 
type  of ‘Text”,  for  example,  this  attribute  will  have  truth  value  of  “false”.  All  other 
answer  types  will  result  in  a  truth  value  of  “true”. 

4.  Specific_Softwarc_Characteristic  (SSC)  -  This  is  the  instantiation  of  the  CSC 
after  it  has  been  evaluated.  The  “value”  attribute  contains  the  functional  results  in  a  form 
that  is  defined  by  the  answer  type  in  its  corresponding  CSC.  The  "tep”  maps  to  the  TEP 
of  Figure  2  and  represents  the  same  information. 


5.  Weight_sct  -  Contains  the  names  of  stored  weight  .sets  for  specific  high  level  tool 
domains.  The  default  attribute  is  a  B(X)lcan  that  determines  if  this  weight  .set  is  a  default 
weight  set. 
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6.  Selection_Sel  -  Contains  the  names  of  sets  of  tools  that  were  considered  and 
stored  by  a  selector. 

7.  The_Quality  -  This  entity  has  a  quality_name  attribute  that  can  be  assigned  one  of 
twelve  quality  names  (see  Appendix  A).  The  QUALITY_VALIJE  associated  with  a 
specific  QUALITY_NAME  is  an  integer  score  (between  0  and  10)  arrived  at  by  an 
evaluator  based  on  a  TEP. 

8.  The_Evaluator  -  Represents  specific  evaluator  information  about  the  person  who 
evaluated  a  SSC  for  a  tool  in  a  given  functional  domain. 

The  non-trivial  relationships  (non-trivial  meaning  that  the  relation  tables  contain 
attributes  in  excess  of  the  mandatory  inherited  key  attributes)  are  as  follows. 

1.  tooLscore  -  Given  a  weight  set  and  a  tool  this  relation  provides  the  overall 
function  and  quality  score  of  a  tool  within  the  context  of  a  domain. 

2.  software_char_score  -  Given  a  weight  set  and  a  SSC  this  relation  provides  a 
function  and  quality  score  for  that  particular  SSC  within  the  context  of  a  domain. 

3.  software_char_weight  -  Given  a  weight  set  and  a  GSC  this  relation  provides  the 
specific  function  and  quality  weight  for  the  GSC. 

STEMclB  Interface  Design  Description.  There  were  two  types  of  interfacing 
that  [19j  de.scribcd,  the  user  interface  and  the  functional  tool  .subsystem  interface  to  the 
database  sub.system.  Although  the  user  interface  was  not  required  to  adhere  to  any 
particular  graphical  user  interface  (GUI)  .standards,  the  design  did  specify  that  a  GUI 
would  be  u.sed.  The  t(X)l  interface  between  database  and  STEMdB  application  was 
defined  in  ( 1 9:2 1 J  as  in  Figure  7: 

STEMdB  Functional  Design  Description.  A  top  level  description  of  the 
functional  requirements  was  already  provided  earlier  in  the  Implementation  Design 
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Description  section.  The  reader  is  referred  to  [19]  for  a  detailed  description  of  the 
functional  components  of  the  design.  A  flavor  for  these  details  will  be  provided  in  the 
analysis  section  of  this  chapter  which  follows. 
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Figure  7.  STEMdB  Basic  Components 


Analysis 

Areas  Well  Designed.  In  genera!  the  STEMdB  effort  had  accomplished  a  lot  of 
good  work  towards  creating  the  end  product  of  the  STEMdB  tool.  The  developing 
organization  understood  the  need  to  learn  more  about  the  problem  space  and  used 
prototyping  as  a  means  to  help  firm  up  requirements.  To  accomplish  this  prototyping, 
two  prototyping  efforts  were  launched.  The  first  effort  resulted  in  a  Think  Pascal 
implementation  that  was  developed  in  the  MacApp  development  environment.  This 
effort  produced  the  three  working  prototypes  referenced  in  (8;  7;  9].  The.se  prototypes 
concentrated  on  modeling  Formulator  and  Evaluator  tool  functionality  more  than  the 
Selector  tool  functionality.  Another  pwxluct  of  this  prototype  stage  was  the  creation  of 
three  HyperCard  Tutorial  stacks  that  were  targeted  towards  training  users  of  the 
prototypes.  The  next  stage  prototypel  19:31  was  an  ongoing  effort  that  was  described  in 
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the  requirements  document.  Its  purpose  was  to  show  how  the  STEMdB  would  work  with 
a  database  storage  facility,  and  to  show  how  the  user  would  interface  with  a  STEMdB 
tool. 

Much  of  the  functionality  described  in  the  requirements  document  and  the 
prototyping  efforts  showed  the  developing  organization’s  dual  concerns  for  providing 
both  a  useful  tool  and  a  user  friendly  tool.  The  following  section  identifies  some  of  these 
requirements. 

The  design  addresses  how  to  process  data  from  multiple  evaluators  by  merging 
evaluati(Mi  trees.  The  design  also  specifies  that  a  Graphical  User  Interface  will  be  used. 
The  design  partially  addresses  the  issue  of  helping  the  user  by  providing  textual 
information  on  the  Formulator  and  Evaluator  processing.  The  design  identifies  that  a 
database  could  contain  incomplete  information  from  both  Formulator  and  Evaluator 
processing.  Incomplete  information  in  this  sense,  however,  is  an  added  functionality  of 
these  two  tools,  since  a  user  is  released  from  the  requirement  of  having  to  complete  a 
session  in  one  sitting.  The  design  also  addresses  one  aspect  of  maintainability  from  the 
viewpoint  of  supporting  a  rapidly  changing  data  model.  Since  identifying  characteristics 
of  tools  could  change  frequently  (due  to  the  ever-increasing  improvements  to  software 
design),  the  design  will  address  how  an  old  data  model  can  be  mapped  onto  a  new  design 
[19:12].  Although  this  mapping  concept  was  identified  in  the  requirements  document  as 
necessary,  no  design  was  presented  at  the  time  of  this  research. 

Areas  That  Require  More  Work.  Even  though  the  prototyping  efforts  produced 
many  valid  design  requirements,  questions  still  remained  about  the  design’s 
maintainability  and  upgradeability.  This  researcher  identifies  two  top  level  areas  that 
require  more  work  due  to  a  lack  of  maintainability  and  upgradeability  in  design 
considerations  and  unnecessary  data  and  functional  limitations.  The  first  area  identified 
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discusses  new  approaches  to  designing  the  STEMdB  tool  that  support  upgradcability  and 
maintainability  requirements.  The  second  area  identified  addresses  improvements  that 
can  be  made  within  the  context  of  the  present  toots  data  2  unctional  designs. 

New  Approaches  to  Designing  the  STEMdB  Tool.  This  section  is  divided  into 
two  new  approaches  for  the  present  design.  The  first  approach  presents  an  argument  for  a 
change  in  design  methodology,  the  second  approach  presents  an  argument  for  setting  a 
higher  goal  for  system  maintainability  and  upgradeability.  Both  arguments  complement 
one  another. 


A  Change  in  Design  Methodology.  The  STEMdB  was  designed  from  a 
functionally  oriented  approach.  In  the  STEMdB  requirements  document  the  Front  End 
module  was  identified  as  providing  all  the  functionality  of  the  STEMdB  tool.  It 
controlled  the  Formulator,  Selector  and  Evaluator,  while  providing  .scoring,  reporting, 
interfacing,  database  initialization,  and  a  user  interface  [19:22].  Since  the  STEMdB  was 
designed  with  behavioral  goals  that  map  closely  to  the  behavioral  goals  of  the  Lawlis 
dissertation  tool  ASSIST,  the  STEMdB  tool  is  a  decision  support  tool.  Lawlis  states  that 
there  is  ”a  strong  relationship  among  the  object  oriented  concepts  and  knowledge 
representation  concepts  of  frames  and  .semantic  nets”  [24:55].  She  further  states  that  if  a 
decision  support  tool  “uses  these  knowledge  representation  concept^”,  it  should  naturally 
follow  that  the  tool  be  developed  using  object  oriented  concepts  [24:55].  'fhe  STEMdB 
is  developed  based  on  the  idea  of  frame  ba.sed  knowledge  and  .semantic  nets.  The 
description  tree  is  a  semantic  net  and  each  n(xlc  contains  a  frame  of  knowledge. 
Therefore,  it  should  naturally  follow  that  the  STEMdB  be  developed  using  an  object 
oriented  design  approach  in.stead  of  the  present  functional  decomposition  approach.  In 
addition,  if  the  STEMdB  is  a  t<x)l  that  will  lx:  utilized  over  many  years  then 
upgradeability  and  maintainability  become  an  issue.  In  the  functional  decomposition 
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designs  of  past  and  present,  maintainability  and  upgradeability  are  hampered  by  designs 
whose  state  information  is  dispersed  throughout  the  functional  modules.  Borland  is  one 
example  of  a  commercial  company  that  has  switched  to  object  oriented  programming  in 
all  of  their  products  and  is  reaping  the  rewards  of  this  new  methodology.  In  an  October 
1991  US  News  and  World  Report  news  release,  Borland  claimed  that  the  Object 
Oriented  Design  (OOD)  methodology  cut  new  upgrade  release  development  time  one 
third  to  a  half  while  also  reducing  lines  of  source  code.  In  the  article,  Borland  used  their 
old  way  of  doing  business.  Structured  Analysis  and  Design  (SADT)  and  Functional 
Decomposition,  as  a  benchmark  for  these  assertions.  Changing  the  design  approach 
could  reap  similar  rewards  for  the  STEMdB  when  it  comes  time  to  maintain  and  upgrade 
it.  Besides,  much  of  the  work  that  has  already  gone  into  developing  the  STEMdB 
prototype  efforts  can  also  be  used  in  an  object  oriented  approach. 

The  Lawlis  dissertation  lays  the  framework  for  an  object  oriented  approach. 

Chapter  IV  shows  how  die  STSC  design  can  be  re-accomplished  using  this  framework. 

Improving  System  Maintainability  and  Upgradeability.  According  to  the 
design,  the  STEMdB  was  targeted  for  one  platform  that  supported  one  type  of  SQL 
database.  Furthermore,  the  STEMdB  implementation  language  could  not  be  Ada  since 
requirements  nine  and  ten  in  the  Design  Description  Section  of  this  chapter  explicitly 
stated  that  the  implementation  language  must  be  supported  by  a  database  provided 
interface.  At  the  time  of  this  research  there  were  no  knowr  'QL  commercial  databases 
that  provided  interfaces  in  the  Ada  language.  By  eliminating  Ada  as  an  implementation 
language  and  by  restricting  the  tool  to  operation  in  one  specific  environment,  the 
developing  organization  was  not  providing  for  long  term  maintainability  or 
upgradeability. 


31 


Ada  provides  many  of  the  capabilities  that  support  good  software  engineering 
practices  which,  when  properly  implemented,  can  create  a  more  maintainable  application. 
The  language  provides  strong  typing,  the  mechanisms  for  information  hiding  and  the 
ability  to  communicate  with  other  implementation  languages.  It  also  provides  the 
capability  to  create  abstract  interfaces  in  software  applications  which  can  be  used  to 
establish  hardware  independence.  For  instance,  when  a  software  application  using  an 
abstract  interface  must  be  re-hosted  on  a  different  machine,  the  implementation  part  in  the 
body  of  the  interface  will  need  to  be  revised  but  the  rest  of  the  application  logic  and 
structure  will  remain  unaffected.  Since  Ada  can  communicate  indirectly  with  SQL 
databases  through  pragmas,  it  becomes  a  candidate  implementation  language  for  the 
STEMdB.  Further,  since  the  Department  of  Defense  (DOD)  edict  states  that  all  DOD 
software  developments  will  be  accomplished  in  Ada  unless  it  is  not  cost  effective  [4J,  the 
STEMdB  must  be  developed  in  Ada .  Using  Ada  to  communicate  with  a  database  opens 
up  a  further  design  decision  as  to  how  to  approach  this  interface  design.  At  the  time  of 
this  research  much  of  the  procedural  program  interfacing  with  databases  used  a  de  facto 
standard  of  pre-compiler  technology  [14:31.  Pre-compiler  technology  was  a  method  used 
for  embedding  SQL  statements  within  a  procedural  application  program  like  Ada. 

Chastek  et  al.  warns  against  using  this  technology  in  the  development  of  Ada  applications 
since  it  in  effect  creates  a  new  language  that  “...no  longer  conforms  with  the  Ada 
Standard.”  [14:3J.  A  .solution  to  creating  an  Ada  to  SQL  binding,  or  an  interface 
independent  of  pre-compiler  technology,  was  c.stablished  by  the  work  accomplished  in 
[14;  13;  17;  16).  The  mtxlel  developed  by  Graham  ct  al.  [  14;  13;  17;  16]  is  called  the 
Structured  Query  Language  Ada  Mcxlulc  Extensions  (SAME)  and  will  be  di.scus.sed  in 
detail  in  Chapter  IV.  A  solution  design  using  the  requirements  of  the  STEMdB  will  also 
be  presented  in  that  chapter.. 
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Top  Level  Requirements  Change.  A  significant  area  in  the  STEMdB 
design  that  was  not  addressed  by  the  requirements  was  the  identification  of  end  users  of 
the  STEMdB  tool  itself.  Due  to  the  widespread  need  for  this  type  of  tool  in  both  industry 
and  the  government,  and  due  to  the  limited  resources  of  any  DOD  organization,  the  tool 
should  be  developed  with  remote  usage  users  and  multiple  platform  configurations  in 
mind.  Building  on  the  concept  of  abstract  interfacing  and  hardware  independence, 
extending  the  STEMdB  requirements  to  support  remote  users  and  multiple  platform 
configurations  becomes  trivial.  The  requirements  should  reflect  this  as  a  design  goal. 
Given  that  this  is  a  valid  requirement,  the  following  implications  must  be  addressed  by 
the  design: 

1,  With  the  many  variables  associated  with  CASE  tool  selection,  the  tool  should  be 
built  and  tailored  as  a  decision  support  system.  It  should  be  built  so  that  a  user  who  has 
no  previous  knowledge  of  evaluation  and  selection  processes  can  use  it  effectively. 
Decision  support  systems  do  not  have  the  expen  knowledge  that  an  expert  system  has, 
but  they  do  have  some  degree  of  domain  knowledge  which  allows  them  to  provide  the 
user  with  an  informed  decision.  With  this  in  mind  and  armed  with  the  knowledge  of 
information  proliferation  from  Chapter  I,  any  tool  that  helps  reduce  volumes  of 
information  into  some  useable  form  benefits  all  users.  This  can  be  understood  by  looking 
at  the  only  alternative  to  such  a  tool  which  would  be  a  user  inept  at  evaluation  and 
selection  processes  attempting  to  select  an  appropriate  CASE  tool.  Such  a  user  more  than 
likely  would  accomplish  an  ad  hoc  evaluation  and  selection  with  limited  information  that 
may  not  meet  his/her  needs. 

2.  Incremental  development  would  allow  various  phases  to  the  tool  to  be  developed 
to  meet  the  goal  of  remote  usage  with  multiple  platform  configuration.  The  first  phase 
would  involve  strictly  in-house  use  at  the  S'fSC,  the  second  phase  would  involve  the 
STSC  sending  personnel  out  to  remote  locations  (hx’ations  other  than  the  STSC)  to  both 


test  the  remote  database  access  and  the  remote  application  operation.  Remote  testing 
could  also  involve  a  joint  training  session  with  the  remote  organization  on  how  to  operate 
the  STEMdB  tool.  The  next  phase  would  allow  pilot  remote  organizations  trained  in  the 
correct  usage  of  STEMdB  to  operate  it  remotely  and  supply  feedback.  These  first  three 
phases  would  have  to  be  repeated  for  all  target  platform  configurations.  The  final  phase 
for  any  configuration  would  involve  providing  both  the  tool  and  tool  training  to  any 
organization  that  has  a  need  and  that  has  the  remote  interfaces,  software  and  hardware  to 
support  the  tool. 

One  of  the  major  problems  associated  with  this  type  of  approach  is  the  complexity 
that  results  from  relationships  between  different  hardware  platforms,  different  user 
interfaces,  and  different  database  interfaces.  This  complexity  can  be  reduced  by 
designing  the  system  around  abstract  interfaces  to  these  areas.  The  STEMdB  itself  would 
have  to  be  configured  by  using  “concrete  interface”  [17:6]  modules  in  the  implementation 
part  of  an  abstract  interface.  Concrete  interface  modules,  according  to  Graham,  arc  the 
modules  that  are  implementation  dependent.  The  use  of  concrete  interface  modules  along 
with  their  enclosing  abstract  interfaces,  would  allow  an  application  such  as  the  STEMdB 
to  be  portable  across  different  configurations.  As  the  need  for  more  remote  platform 
support  becomes  necessary,  the  STSC  would  have  the  option  of  extending  the  STEMdB’s 
target  platform  domain  to  meet  this  need.  In  addition,  the  STSC  could  provide  to  the  Ada 
software  development  community  a  libraiy  of  these  interfaces.  The  Ada  development 
community  would  then  have  the  capability  of  making  their  Ada  applications  more 
portable  across  different  configurations. 

The  one  interface  in  this  section  that  may  not  be  feasibly  abstracted  is  the  user 
interface.  This  may  be  the  case  if  the  STEMdB  user  interface  is  built  using  a 
commercially  developed  user  interface  application.  One  example  of  where  a 
commercially  developed  u.scr  interface  could  not  be  feasibly  ab.stracted  out  of  an 
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application  is  a  HyperCard  program  running  on  a  Macintosh  computer.  This  was 
discovered  by  Lawlis  while  implementing  her  ASSIST  prototype  in  HyperCard. 

3.  Other  design  changes  resulting  from  remote  usage  would  require  that  the 
STEMdB; 

a.  Provide  an  initialization  routine  in  the  abstract  application  interface  that 
creates  the  tables  that  will  mimic  the  database  format  of  the  STSC  database. 

b.  Provide  capability  to  download  and  import  the  data  into  a  users  local 
database.  This  capability  could  initially  be  provided  as  a  manual  procedure.  In  this  case, 
users  must  understand  how  to  import  data  based  on  their  own  database  and  the  format  of 
the  downloaded  data  (i.e.  comma  separated  text,  tab  separated  text ). 

c.  Add  the  capability  for  the  tool  to  check  downloaded  data  against  a  date  flag. 
By  ensuring  that  upon  “download  date  expiration”  any  further  selection  work  will  not  be 
allowed  to  proceed  unless  new  information  is  downloaded,  the  STEMdB  will  help 
maintain  the  data  currency  requirements.  Due  to  consistency  considerations  that  local 
database  information,  additional  capabilities  will  need  to  be  provided  for  local  database 
currency  updates.  For  instance,  the  local  weight  set  data  will  be  updated  with  any  new 
default  weight  set  data  in  the  currency  update  process.  If  steps  are  not  taken  to  preserve 
the  original  user  defined  weight  set  data,  it  could  be  overwritten  in  the  update  process. 
Similarly,  the  remote  tool  will  need  to  be  sure  not  to  upload  any  Selection_Sct 
information  (since  this  information  only  makes  sense  when  the  remote  user  identifies  tool 
sets  important  to  his/her  organization)  and  it  will  have  to  provide  for  restoring 
softwarc_char_wcights.  Two  constraints  that  must  be  checked  on  the  newly  uploaded 
data  would  be  that  all  restored  linkSTToolJD  entries  have  matching  t{X)ls  in  Thc_T(X)l 
and  that  all  restored  GCS_ID’s  in  software_char_ weight  have  matching  GCS_lD’s  in  the 
General  Software  Characteristic  table.  These  consistency  checks  arc  necessary  since  the 
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newly  uploaded  data  may  have  added  or  deleted  information  that  the  earlier  system  used. 
For  instance,  a  tool  could  have  been  deleted  from  the  database. 

d.  Finally,  the  remote  tool  should  be  able  to  check  an  application  integrity 
constraint  that  would  guarantee  that  the  remote  application  and  the  STSC  database  are 
compatible.  This  would  ensure  that  there  were  no  structural  revisions  to  the  database 
design  after  the  STEMdB  remote  application  was  released. 

Improvements  to  Be  Made  Within  Context  of  Present  Design.  This  section  will 
suggest  improvements  to  the  Data  model,  the  Formulator  functionality,  the  Evaluator 
functionality,  and  the  Selector  functionality. 

Data  Model.  There  were  six  areas  that  needed  to  be  addressed  further 
within  the  Data  Model. 

The  first  area  concerns  the  relational  database  design  goals  of  Boyce-Codd  normal 
form/Third  normal  form(BCNF/3NF),  lossless  join  decompositions  and  dependency 
preservation.  According  to  [23:209]  these  design  goals  are  principle  criteria  for  good 
relational  database  design.  The  overall  minimal  requirement  in  any  database  design  is  to 
reduce  update  redundancies  while  preserving  functional  dependencies.  Either  normal 
form  accomplishes  the  goal  of  reducing  update  redundancies  with  BCNF  also  minimizing 
those  redundancies.  The  difference  between  BCNF  and  3NF  is  that  3NF  is  a  less 
restrictive  form  (it  can  have  some  redundancy)  that  maintains  functional  dependency 
preservation  whereas  the  BCNF  form  is  a  more  restrictive  form  that  guarantees  minimal 
redundancy  at  the  possible  cost  of  dependency  prc.scrvation.  A  definition  of  BCNF  form 
is  provided  in  the  following  analysis  sections.  Since  3NF  form  was  not  needed  in  the 
following  analysis  sections,  its  definition  is  not  discus.sed.  Dependency  preservation 
means  that  after  a  database  .scheme  is  decomposed  into  its  sub  schemes,  each  of  the 
problem  space  dependencies  “can  be  tested  in  at  least  one  relation  in  the  decomposition” 
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[23:182].  According  to  [23:181],  when  accomplishing  relational  decomposition, 
designers  must  ensure  lossless  decomposition/joins.  This  means  that  the  designer 
decomposes  a  scheme  so  that  no  functional  dependencies  are  lost  as  a  result  of  the 
decomposition  [23:184].  There  was  no  indication  in  the  STEMdB  documentation  of 
requiring  any  of  the  design  goals  discussed  in  this  paragraph. 

Without  knowledge  of  how  the  STEMdB  relational  data  model  was  designed,  more 
confidence  in  the  design  had  to  be  gained.  To  gain  this  confidence,  a  canonical  cover 
with  dependencies  defined  in  Table  1,  was  derived.  A  canonical  cover  is  a  minimal  set  of 
functional  dependencies  that  fully  defines  a  schema  with  minimal  repetition  of 
information.  A  canonical  cover  of  dependencies  must  be  able  to  completely  derive  all 
original  dependencies  without  adding  any  additional  information.  The  form  of  each 
component  functional  dependency  in  the  cover  is  required  to  have  a  unique  left  hand  side. 
Table  1  lists  one  possible  cover  that  fully  defines  the  STEMdB  Schema  [5],  The  syntax 
T  =>  A  is  read  “T  implies  A”. 

For  better  readability  of  candidate  key  results,  and  for  functional  dependency 
processing  derivation,  it  is  desirable  to  represent  keys  in  some  abbreviated  form.  The 
acronyms  used  in  Table  1  represent  the  keys/attributes  of  Figure  6.  In  general,  if  a  list  of 
attributes  was  defined  by  long  words  in  Figure  6,  for  instance  the  software_char_score 
non-key  attributes,  then  the  acronym  used  to  describe  this  li.st  was  written  with 
distinguishing  capital  letters  followed  by  an  ‘•_a”.  One  example  of  an  acronym 
conversion  follows:  The  softwarc_char_score  non-key  attributes  in  long  hand  would  be 
written  “function_.score,  quality_scorc”,  but  this  new  notation  reduces  to  the  following 
notation:  SCS_a.  When  a  key  attribute  was  represented  in  shorthand,  it  was  just 
distinguished  by  an  obvious  .set  of  capital  letters.  Tabic  2  maps  the  acronyms  of  Tabic  I 
to  the  key.s/attributcs  they  represent  in  Figure  6. 
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Table  1.  Functional  Dependencies  of  STEMdB  Schema 


GSC,T 

SSC_a,  Parent_GSC 

WS,  GSC 

SCW_a 

A 

GSC 

WS,  T,  GSC 

SCS_a,  TS_a 

EVAL 

date 

WS 

=> 

default 

GSC 

GSC_a,  A 

T 

=> 

T_a 

QUAL 

=> 

QUAL_a 

The  main  result  of  the  derivation  of  a  canonical  cover  was  the  identification  of  a 
STEMdB  functional  closure.  Closure  analysis  identified  {T,  A,  WS,  EVAL,  QUAL}  or 
{T,  GSC,  WS,  EVAL,  QUAL>  as  the  candidate  keys.  Candidate  keys  provide  the 
minimum  functional  information  a  database  schema  must  have  to  fully  identify  all 
functional  dependencies.  This  analysis  shows  that  given  an  Area  or  GSC,  a  Weight  Set,  a 
Tool  and  evaluator/quality  information  ail  other  dependencies  in  the  database  can  be 
derived.  The  candidate  key  with  the  GSC  in  it  will  only  work,  however,  if  that  GSC  is  a 
root  node  in  the  present  design. 

Upon  further  analysis  each  relation  .scheme  of  the  STEMdB,  in  the  original  Figure  6, 
tur.is  out  to  be  in  a  BCNF  form  that  is  dependency  prc.scrving.  This  is  true  since  all  but 
two  relations  were  of  the  form  of  Super  Key  =>  attributes.  To  check  for  dependency 
preservation,  any  relation  that  has  functional  dependencies  beyond  those  of 
Super  key  attributes  must  have  the.se  dependencies  prc.scrvcd  and  accounted  for  in  the 
cover  analysis.  The  two  relations  that  had  additional  constraints  were  the  r(X)t_n{xlc  and 
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the  linkGG.  Additional  constraints  surface  whenever  there  is  a  one  to  one  or  a  one  to 
many  relationship.  The  two  additional  functional  dependencies  resulting  from  the  one  to 
one  relationship  iDetween  The_Area  and  the  General  Software  Characteristic  were 
incorporated  into  Table  1  and  were  maintained  in  the  design  by  the  cardinality.  The  same 
can  be  said  for  the  child  GSC_ID  determining  its  Parent  GCS_ID,  which  results  from  the 
one  to  many  relationship  in  linkGG.  Since  all  relations  that  make  up  the  STEMdB  are  in 
dependency  preserving  BCNF  form,  the  STEMdB  Schema  is  in  BCNF.  These  results 
allowed  this  researcher  to  conclude  that  the  schema  now  reflected  the  database  design 
goals  established  earlier. 

During  the  course  of  this  analysis  a  problem  was  discovered  in  the  context  of  the 
problem  space,  however.  Ambiguities  were  resulting  from  the  design  using  two  binary 
relationships  to  define  the  tool_score  relationship.  This  relationship  is  truly  a  three  way 
relationship  that  depends  on  a  root  GSC  node,  a  tool  and  a  weight  set.  By  designing  it  as 
a  binary  relationship  the  integrity  of  the  data  was  compromised.  The  best  way  to  show 
this  is  through  a  .scenario  that  uses  the  structure  of  Figure  6. 

1.  Given  a  tool,  Tl,  that  maps  to  two  evaluation  domains,  A1  and  A2  through  two 

root  GSC  nodes,  G1  and  G2. 

2.  Given  one  weight  set,  WS 1 ,  that  maps  to  both  G1  and  G2. 

3.  Provide  the  tool_.scorc  for  Tl  using  WSl. 

As  the  reader  can  surmise  there  arc  actually  two  different  domain  dependent  scores  that 
the  t(X)l  can  be  a.ssigncd  based  on  whether  A 1  or  A2  is  selected.  This  ambiguity  can  be 
eliminated  from  the  design  by  specifying  a  GSC  that  defines  which  domain  the  .score  is 
desired  in.  The  original  STSC  design  omitted  the  key  attribute  of  GSC_ID.  The  redesign 
in  Figure  8  implements  this  correction  by  connecting  the  t(X)l_.scorc  relation  to  the 
Software  Char  Weight  aggregate  thus  inheriting  the  GSC._1D  key  from  it. 
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Table  2.  Map  of  Table  1  ’s  Relationship  to  Attributes 


T 

= 

TOOL_ID 

A 

ss 

AREA_ID 

EVAL 

= 

EVALJD 

QUAL 

= 

QUALJD 

GSC 

= 

GSCJD 

T_a 

= 

The_Tool  non-key  attributes 

GSC_a 

= 

General  Software  Characteristic  non-key  attributes 

WS 

ts 

WEIGHT_SET_NAME 

SCW_a 

- 

software_char_weight  non-key  attributes 

SCS_a 

= 

software_char_score  non-key  attributes 

TS_a 

= 

tooLscore  non-key  attributes 

EVAL_a 

The_Evaluator  non-key  attributes 

Parent_GSC 

■e 

Parent_GSC_ID 

0UAL_a 

= 

The_Quality  non-key  attributes 

The  second  area  that  needed  to  be  addressed  further  within  the  Data  Model  concerns 
table  optimizations  that  can  be  made  in  the  design.  The  original  STSC  design  lacked  any 
reference  to  a  relationship  called  root_nodc  between  the  Thc_Arca  and  the 
General_Software_Charactcristic  entities.  The  design  of  Figure  5  references  the 
theSEATree  as  a  link  in  the  The_Area  table  and  it  references  the  keys  of  the  The_Area 
table  as  a  key  in  the  General_Soft_Charactcristic  table,  yet  the  rest  of  the  design  never 
references  how  the.se  are  connected.  It  appears  as  though  the  system  designers  were 
incorporating  an  optimized  design  into  the  requirements  dtKument  while  omitting  the 
source  design.  According  to  Dr.  Roth  in  |6j,  it  is  imponant  to  keep  a  record  of  the 
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original  design  prior  to  any  implementation  optimizations.  In  order  to  re-host  the  design 
(Ml  a  different  target  architecture  (on  a  distributed  system  for  instance)  at  some  future 
date,  this  record  along  with  a  record  of  optimizations  will  help  to  prevent  any  reverse 


Figure  8.  Entity  Relationship  Diagram  Revised 
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By  incorporating  a  root_node  linking  relationship  (as  shown  in  both  Figures  6  and 
8)  the  connection  between  tbe  General_Software_Characteristi:  and  the  The_Area  tables 
can  be  established  and  any  previous  optimization  is  eliminated.  Since  the  basis  for  the 
previous  optimization  was  not  stated,  it’s  existence  could  not  be  justified.  The  one  to  one 
nature  of  the  new  root_nodc  relationship  implies  that  table  optimization  can  be 
accomplished  by  eliminating  the  root_node  relationship  table  and  by  adding  keys  to  the 
appropriate  tables.  Since  Tlie_Area  requires  exactly  one  root  GSC  node,  the  GSC_ID  of 
the  root  node  can  be  linked  to  exactly  one  entry  of  the  The_Area  table  by  adding  it  as  an 
attribute.  Since  a  GSC  docs  not  necessarily  have  to  be  linked  to  an  entry  in  the  The_Area 
table,  adding  an  AREAJD  key  to  the  General  Software  Characteristic  table  would  be  a 
waste  of  storage  space  for  the  design  in  this  chapter.  Consider,  for  instance,  that  only  one 
node  of  all  GSC’s  for  an  area  must  have  an  AREAJD  attached  to  it.  All  other  GSC’s 
have  an  implied  association  with  that  area  through  their  linkage  to  the  root  node. 
Therefore  by  adding  the  attribute  of  root_nodeID  to  the  Thc_Area  table  and  eliminating 
the  need  for  the  root_node  relation,  functional  dependency  between  the  two  entities  is 
maintained  while  storage  space  is  saved.  The  original  design  which  a.ssociated  an  area 
with  every  GSC  was  wasteful  unless  the  developers  had  a  design  goal  that  was  not 
specified  in  the  requirements  document.  By  eliminating  the  linkGG  table  and  placing  a 
parent_GSCJD  key  in  the  GSC  table,  another  table  optimization  can  be  established. 

This  would  be  functionality  correct  since  every  GSC  ha.s  exactly  one  parent,  except  for 
the  root  node  GSC  which  has  a  null  parent. 

Another  interesting  twist  to  the  old  design  can  be  seen  by  concentrating  on  the 
hierarchy  of  GSC’s.  Early  in  the  research  a  STEMdB  designer  commented  that  the  GSC 
structure  was  more  of  a  directed  graph  than  a  tree  since  it  could  have  more  than  one 
parent  a.ssigned  to  the  same  child.  Allowing  this  type  of  design  would  save  space  with 
common  GSC’s  shared  by  different  description  trees.  Since  the  original  design  had  an 
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Area  associated  with  every  GSC  node,  there  would  have  to  be  a  way  of  coding  multiple 
Areas  into  each  GSC  node.  Associating  multiple  areas  with  one  GSC  node  would  change 
the  cardinality  of  the  original  design  to  many  to  many  and  would  require  that  another 
relationship  table  be  added  to  the  original  relational  design  of  Figure  5.  During  this 
research,  the  multiple  parent  concept  was  discarded  by  the  STEMdB  designers.  The 
complications  associated  with  this  type  of  design  were  determined  to  out-weigh  any  of 
the  benefits.  From  one  perspective,  this  could  be  considered  a  good  design  tradeoff 
decision  since  it  does  reduce  the  complexity  of  the  design.  From  the  big  picture 
perspective,  this  design  decision  may  have  placed  unnecessary  restrictions  on  the  design 
too  early.  Chapter  V  will  present  a  more  detailed  argument  against  early  re.strictive 
design  decisions. 

The  third  Data  Model  area  requiring  re-work  concerns  the  naming  conventions  used 
in  [19:26-28].  The  relationships  Tool_Score,  The_Score  and  The_Weight  are  not  listed 
in  the  linking  relations  section  of  the  design  document.  These  three  relations  are  linking 
relations  as  can  be  seen  by  their  counterparts  of  Figure  6,  therefore  they  should  be 
identified  as  such. 

The  founh  area  has  to  do  with  optimization  questions  about  the  Specific  Software 
Characteristic  table.  The  Specific  Software  Characteristic  entity  can  be  thought  of 
conceptually  as  consi.sting  of  itself,  The_Rvaluator  and  The_Qualiiy  entities.  The  present 
design  requires  table  joins  to  be  accomplished  between  the  Specific  Software 
Characteristic  and  The_Evaluator  and  the  Specific  Software  Characteristic  and 
Thc_Quality  tables  through  the  linking  tables  of  each.  Join  operations  arc  time  expensive 
when  one  considers  that  the  underlying  operation  depends  on  .searching  for  matching 
attributes  in  the  cro.ss  prcxluct  of  two  table’s  entries.  'I’o  access  all  SSC  data  on  any  area, 
the  access  time  will  be  of  order  (Number  of  Specific  Software  Characteristics  *  Join  time 
required  per  characteristic  fetch).  This  Join  time  is  functionally  dciicndcnt  on  the  si/x  of 


the  Specific  Software  Characteristic  table  (maximum  =  1000  entries),  the  Evaluator  table, 
the  Quality  table,  their  linking  tables,  and  the  efficiency  of  the  search  algorithm.  If 
memory  space  is  not  a  limitation,  the  lag  time  associated  with  the  present  design  can  be 
eliminated  by  placing  all  of  the  attributes/keys  into  one  table,  the  Specific  Software 
Characteristic  table.  A  drawback  of  this  is  the  limitations  that  result  from  a  fixed  design 
of  the  number  of  allowable  entries  of  evaluators  and  quality  values  per  characteristic. 

The  fifth  area  concerns  the  re-design  of  the  conceptual  relationships  of  the 
Selection_Set  and  the  Weight_Set. 

Selection  Set  Re-design.  Presently  the  Selection_Set  retains  only  a  list 
of  tools  that  were  evaluated  under  some  domain  and  some  weight  set.  To  remind  the 
selector  of  the  original  context  of  the  selection  set,  an  automatic  connection  to  both  an 
area  and  a  weight  set  should  be  associated  with  all  selection  sets.  To  address  this  design 
in  the  data  model,  a  four  way  relationship  link  could  be  created  connecting  the 
Selection_Set,  The_Tool,  The_Area  and  the  Weight_Set.  Figure  9  shows  what  this 
would  involve  for  the  entities  discussed.  The  linkSAWT  relation  would  then  replace  the 
linkST  relation  of  Figure  8. 

Weight  Set  Re-design.  For  more  flexibility  of  the  design,  there  .should 
be  three  levels  of  default  weight  sets:  the  automatic  default  that  a.ssigns  all  nodes  within 
the  .same  level  equal  weights,  an  explicit  Formulator  system  default  that  a.ssigns  weights 
to  ncxles  based  on  empirical  evidence  for  a  domain,  and  the  user  definable  default.  This 
design  could  be  implemented  with  an  optional  one  to  one  relationship  between  the 
The_Area  and  the  Wcight_Set  tables  or  it  could  be  implemented  with  access  time 
optimization  by  adding  the  attribute  of  systcm_default_weight_sct_namc  toThc_Arca 
table.  One  other  way  of  implementing  this  would  be  to  add  an  ‘*cmpirical_wciglit” 
attribute  to  the  GSC  Table.  This  re-dcsign  would  require  that  the  Formulator  be 
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re-designed  to  create  and  store  the  default  weights.  A  further  justification  for  this  re¬ 
design  will  be  presented  in  the  analysis  section  on  Formulator  functionality. 


TOOL_ID 

TOOL_NAME 

VERSION 

vendor 

cost 


Figure  9.  Selection_Set  Redesign 


The  sixth  area  concerns  a  more  extensive  conceptual  description  of  the  data  design. 
Although  a  section  on  referential  integrity  was  provided  in  the  STEMdB  requirements 
and  design  document,  a  conceptual  discussion  of  the  entities  was  not  provided.  A 
conceptual  discussion  provides  a  better  word  picture  of  how  entities  relate  to  one  another 
and  how  they  affect  one  another  upon  updatc/delction.  The  following  presents  a 
suggested  solution  to  this  problem: 


45 


Conceptual  Description  of  the  Data  Model.  The  conceptual 
relationships  between  the  different  entities  in  Figure  6  can  be  understood  by  considering 
the  optionalites  and  cardinalities  as  follows: 

1.  The_Tool  -  Has  a  mandatory  relationship  with  both  the  Selection_Set  and  the 
SSC.  This  implies  that  eliminating  a  tool  from  the  database  would  cause  records  in  the 
Selection_Set  table  to  be  deleted  if  the  tool  was  a  member  of  hat  selection  set.  The  same 
can  be  said  for  the  connection  with  the  SSC  table.  If  a  tool  was  deleted  then 
characteristic  values  evaluated  for  the  tool  would  no  longer  make  sense  to  the  STEMdB 
model.  Eliminating  a  tool  would  not  affect  the  integrity  of  the  Weight_Set  or  The_Area 
entities,  however. 

There  can  be  many  tools  associated  with  many  areas  or  domains,  selection  sets  and 
weight  sets.  Only  one  tool  can  be  associated  with  many  different  SSC’s. 

2.  The_Area  -  Eliminating  an  area/domain  would  affect  the  integrity  of  the 
The_Tool  entity,  only  if  the  area  eliminated  was  the  only  area  that  a  tool  applied  to.  A 
domain  elimination  also  affects  the  integrity  of  the  GSC  table,  since  there  is  a  one  to  otie 
mapping  through  the  root_node  relation.  This  would  cause  an  entire  description  tree  with 
a  GSC  as  its  root  node  to  disappear,  which  would  result  in  all  related  SSC’s  to  disappear. 

There  can  be  many  domains  for  many  toots  but  there  is  exactly  one  domain  for  one 
root_node  GSC. 

3.  General_Software_Characteristic  -  The  GSC  has  a  mandatory  relationship  with  all 
related  entities  except  for  its  ‘child’  recursive  relation.  Therefore  the  integrities  of  all 
related  entities,  including  itself,  could  be  affected  by  an  elimination  of  an  instantiation  of 
the  GSC. 

4.  Specific_Software_Characteristic  -  This  entity  has  mandatory  relationships  with 
The_Evaluaior  and  The_Qualities.  This  makes  sense  since  these  two  entities  can  be 
considered  a  pan  of  all  unique  SSC’s. 
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5.  Weight_set  -  Has  a  mandatory  relationship  with  the  GSC.  Many  weight  sets  can 
be  associated  with  many  tools,  SSC’s  and  GSC’s, 

6.  Selection_Set  -  This  entity  does  not  have  to  exist  with  respect  to  a  tool.  There  can 
be  many  selection  sets  associated  with  many  tools. 

7.  The_Quaiity  -  The_QuaIity  values  must  exist  for  the  SSC.  Many  different  quality 
records  can  be  associated  with  one  SSC.  This  makes  sense  in  the  context  of  an  evaluation 
since  quality  values  of  one  characteristic  are  associated  only  with  that  characteristic. 

8.  The_Evaluator  -  The_Evaluator  must  exist  for  the  SSC. 

Thic  completes  the  conceptual  discussion  of  the  data  model  as  well  as  the  other  data 
model  discussions.  The  next  three  sections  present  a  discussion  of  functionality  provided 
by  the  three  sub-tools,  the  Formulator,  the  Evaluator  and  the  Selector. 

Formulator  Functionality.  One  improvement  to  the  functionality  of  the 
Formulator  which  could  have  significant  impact  on  the  STEMdB  tool  utilization,  would 
be  to  add  an  empirical  weight  set  insert  capability.  Providing  an  empirically  defined 
default  weight  set,  that  has  a  solid  statistical  basis  for  a  given  CASE  tool  Software  Area 
of  Interest  (SAI),  has  the  potential  to  make  the  STEMdB  Selection  process  more 
automated.  It  would  become  more  automated  by  allowing  the  user  to  choose  an  area  then 
sit  back  and  wait  for  the  resulting  tool  list  suggestions.  The  more  automated  a  system  is, 
the  simpler  it  is  to  operate  and  the  more  usage  it  will  get  provided  its  results  are  valid.  In 
order  to  get  this  statistical  basis,  an  internal  monitoring  routine  could  be  implemented  to 
record  weight  set  information  identified  in  a  STEMdB  session.  The  system  could  also 
provide  an  automatic  reporting  routine  that  the  user  would  u.se  to  send  the  raw  data  to  the 
STEMdB  developing  organization.  This  reporting  capability  addresses  the  feedback 
requirement  that  an  evaluation  and  selection  system  pr(x:ess  must  have  to  continue  to 
improve  [  1 :7 j.  Once  this  capability  is  added  and  g(xxl  statistical  bases  for  cenain  SAI’s 
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are  developed,  the  next  natural  step  would  be  to  add  a  default  weight  attribute  to  the 
General  Software  Characteristic  table.  By  adding  this  attribute  the  initial  setup  of 
searching  the  softwarej  har_weight  table  for  default  weights  could  be  avoided.  If  these 
empirically  defined  weights  do  turn  out  to  be  used  the  most  often,  then  adding  this 
attribute  reduces  total  processing  time. 

The  Formulator  documentation  is  ambiguous  about  the  build  process  and  the 
hierarchy  of  characteristics.  Specifically,  it  does  not  describe  what  types  of 
characteristics  are  and  are  not  allowed  to  structurally  follow  at  a  lower  level  in  the  build 
process.  The  STEMdB  has  five  node  types  that  can  be  assigned  at  any  level  in  the  build. 
Incorrect  hierarchical  ordering  of  the  types  could  nullify  functionality  that  exists  in  a 
node’s  children.  For  instance,  if  a  single  item  checklist  node  is  the  parent  of  a  node  that 
is  an  evaluate  children  type,  and  if  the  single  item  check  node  is  evaluated,  then  the 
functionality  of  the  parent 's  assigned  a  one  and  its  children  do  not  add  or  dedact  from 
this  functionality.  This  result  is  not  consistent  with  the  requirements  that  the 
functionality  of  the  parent  be  determined  by  its  children.  The  Formulator  should  provide 
build  restrictions  on  structures  that  are  illegal  and  these  restrictions  should  be 
documented. 


Evaluator  Functionality.  More  flexibility  should  be  provided  to  allow  for 
multiple  evaluations  of  functions/qualities.  The  STEMdB  design  concentrates  on  a  final 
evaluation  result  for  a  function/quality  that  is  statistically  arrived  at  outside  of  the  scope 
of  the  STEMdB.  The  Lawlis  (24:315-316]  design  accomplishes  this  task  inside  of  her 
tool  by  incorporating  a  “Summary”  package  as  part  of  the  Knowledge  Base.  Pan  of  the 
functionality  of  her  Knowledge  Base  is  to  .statistically  average  different  evaluations  of  an 
implementation  and  store  the  results  of  this  process  in  a  Summary  package.  Both  Lawlis 
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and  the  evaluation  and  selection  team  of  [1]  emphasize  the  need  for  multiple  evaluators  of 
subjective  areas. 

The  design  limitation  of  twelve  quality  attributes  associated  with  every  characteristic 
is  too  restrictive  and  should  be  lifted.  This  researcher  could  find  no  justification  for 
enforcing  this  limit,  other  than  a  user  interface  that  was  tightly  coupled  with  the  design. 
This  restriction  limits  the  STEMdB’s  capability  for  expansion.  The  Knowledge  Base 
discussed  in  Chapter  IV  will  provide  the  evaluator  with  the  qualities  associated  with  the 
STEMdB  at  any  given  time.  The  concept  of  the  selector  viewing  these  qualities  can  also 
be  addressed  by  calls  to  the  Knowledge  Base. 

Selector  Functionality.  The  first  and  most  obvious  area  in  the  Selector 
functionality  that  needs  more  work  is  the  process  of  identifying  and  weighting  important 
tool  characteristics.  The  ASSIST  tool  accomplishes  this  process  by  only  processing  the 
features  and  criteria  that  the  user  identifies  and  assigns  relative  importance  to.  The 
STEMdB  tool  assumes  that  all  nodes  will  be  visited.  Those  nodes  that  are  not  visited  and 
whose  parents  are  not  assigned  a  weight  of  zero,  receive  the  system  default  weight  and 
are  still  used  in  the  selection  process  of  arriving  at  a  score.  This  method  places  the 
unnecessary  restriction  on  the  user  of  processing  a  minimum  number  of  characteristics  in 
order  to  ensure  that  only  his/her  specific  requirements  are  addressed.  For  instance,  if  an 
SAI  tree  had  five  top  levels  of  functionality,  and  the  user  only  wanted  the  tool  to  identify 
candidate  tools  based  on  exactly  two  of  these  areas,  then  the  user  would  have  to  visit  each 
of  the  three  undesirable  nodes  just  to  a.ssign  them  a  zero  weight.  The  simplest  solution  to 
this  problem  is  to  provide  the  user  with  a  resource  that  equates  to  assigning  zero  weights 
to  all  unprocessed  nodes.  This  resource  could  also  be  provided  at  a  higher  level  of 
abstraction  where  the  user  can  toggle  it  on  or  off.  When  on  it  would  monitor  all  nodes 
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processed  and  then  zero  out  all  that  had  not  been  processed  just  prior  to  initiating  the 
scoring  process. 

Another  area  requiring  more  work  is  closely  related  to  the  one  Just  discussed  and  has 
to  do  with  marking  a  characteristic  as  essential  in  the  selection  process.  The  Lawlis 
design  required  that  all  nodes  identified  in  the  process  be  evaluated  favorably  for  a  tool  to 
be  scored  at  all.  The  STEMdB  requires  that  ail  nodes  marked  as  essential  by  the 
Formulator  be  evaluated  favorably  to  be  scored.  It  also  provides  the  user  the  option  of 
marking  each  characteristic  as  essential  but  this  option  is  provided  outside  of  the  process 
of  assigning  weights.  In  effect  for  the  user  to  tailor  the  system  to  his/her  needs,  she/he 
must  go  through  an  additional  process  of  marking  essential  characteristics  while  being 
forced  to  accept  system  defined  essential  characteristics.  The  fact  that  a  user  identifies  a 
characteristic  and  assigns  a  weight  to  it,  strongly  correlates  to  that  characteristics  being 
desirable  and  possibly  essential.  The  STEMdB  should  provide  a  resource  that  when 
toggled  on,  identifies  all  user  visited  and  accepted  characteristics  as  essential.  In 
addition,  a  resource  to  remove  the  Formulator  defined  essential  constraints  from  the 
process  should  be  provided. 

Since  using  a  linear  weighting  approach  to  multiple  criteria  can  result  in  decisions 
that  the  user  may  not  want  ( and  in  the  STEMdB  design  the  user  may  not  know  that 
he/she  has  been  provided  with  a  decision  that  doesn’t  meet  user  criteria),  the  designers 
should  state  explicitly  in  the  design  documentation  how  these  misconceptions  and  bad 
decisions  will  be  avoided.  This  problem  with  a  linear  weighted  approach  to  multiple 
criteria  DSS  systems  is  well  documented. 

Another  area  requiring  re-work  is  the  user  interface  presentation  of  data.  Both  too 
much  information  and  unnecessary  information  arc  provided  to  the  user.  The  concepts  of 
leveling  of  information  and  of  allowing  for  different  user  experience  levels  are  not 
addressed  in  the  STEMdB  design.  For  instance,  the  user  is  provided  with  a  window  that 
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shows  the  characteristic  names  structured  within  the  form  of  an  indented,  numbered, 
scrollable  list.  The  novice  user  does  not  need  to  know  how  the  characteristics  are 
structured  and  he/she  doesn’t  have  to  initially  have  access  to  the  complete  list  of 
characteristics.  After  working  with  the  ASSIST  prototype  from  the  Lawlis  dissertation 
and  after  analyzing  the  STEMdB  design  the  following  conclusions  were  made. 

Abstraction  out  of  a  multi-level  tree  view  and  into  a  default  list  view  at  any  given  level 
will  provide  the  novice  user  with  as  much  information  as  needed.  A  pop-up  menu 
containing  the  remaining  characteristics  at  a  given  level  can  be  displayed  by  the  selector 
when  additional  characteristics  at  a  level  are  desired.  The  Formulator-defined  empirical 
weight  could  be  used  to  indicate  which  characteristics  should  be  presented  at  which  level. 
A  user  experience  level  function  can  be  designed  to  provide  more  information  to  the  user 
based  on  the  experience  level  chosen. 

Another  problem  discovered  in  the  Selector  processing  results  from  an  implicit 
rather  than  explicit  way  of  handling  tool  cut-off  threshold  processing.  Although  the 
STEMdB  design  implicitly  allows  the  user  to  assign  a  threshold  level  by  allowing  the 
user  to  require  that  the  root  node  be  above  a  certain  score,  it  docs  not  di  s  explicitly. 
The  design  also  made  no  mention  of  setting  a  default  cutoff  threshold  for  me  tool  score 
proce.ss.  Both  Lawlis  and  an  IEEE  group  in  [24;  1]  specifically  identify  that  the  user 
must  be  allowed  to  modify  cutoff  thresholds.  Both  references  also  advocate  providing  a 
system  default  cutoff  threshold.  With  this  justification,  the  STEMdB  should  provide  a 
system  default  cutoff  threshold  and  it  .should  explicitly  give  the  user  the  capability  to 
change  this  default. 

Another  unnecessary  functional  restriction  in  the  Selector  results  from  pre.scnting  the 
user  with  two  disjoint  .scores,  one  for  the  functionality  and  one  for  the  quality.  The 
STEMdB  could  easily  present  a  combined  .score  to  the  user.  Adding  this  capability  forces 
the  tool  ranking  mechanism  to  be  altered.  A  single  combined  top  level  ranking  of  scores 
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(based  on  user  defined  weights)  should  become  the  default  ranking  mechanism,  while 
existing  ranking  methods  should  be  made  available  at  another  lower  level  of  detail. 

The  next  area  that  the  designers  of  the  STEMdB  were  negligent  in  addressing  was 
the  concept  of  evaluations  existing  in  different  states  of  completeness  within  the  database. 
Although  the  concept  of  returning  to  marked  areas  to  continue  an  evaluation  was 
addressed,  the  concept  of  allowing  selections  on  these  partially  evaluated  tools  was  not 
addressed.  Lawlis  in  [24]  emphasized  the  importance  of  making  sure  that  evaluations  are 
done  based  on  the  same  criteria.  If  some  GSC  is  not  evaluated  in  one  tool  but  is  in 
another,  would  the  STEMdB  tool  still  compare  the  two  tools  and  score  them?  Since 
partial  evaluations  will  be  allowed,  there  needs  to  be  some  mechanism  for  tracking  when 
a  tool  is  completely  evaluated  within  the  context  of  an  area.  This  mechanism  must  be 
accessible  to  the  Selection  subsystem.  The  STEMdB  designers  could  design  for  two 
levels  of  completeness  in  a  tool  evaluation:  a  degraded  level  and  a  complete  level.  With 
software  updates  and  improvements  happening  so  rapidly,  the  degraded  level  could 
represent  a  set  of  characteristics  that  is  empirically  proven  to  support  most  minimum 
user  selection  criteria.  This  type  of  leveling  would  allow  quick  degraded  evaluations  of 
new  and  upgraded  tools  to  be  accomplished  in  minimal  time.  This  would  also  address  the 
issue  of  maintaining  currency  in  the  evaluation  database.  Another  solution  to  this 
problem  is  addressed  in  the  design  of  ASSIST  [24].  This  design  recognized  that 
evaluation  information  could  be  incomplete  between  different  tools.  Instead  of  forcing 
the  user  to  accept  a  degraded  selection  suggestion,  it  allowed  for  incomplete  evaluations 
by  summarizing  this  incomplete  information  in  a  selection  report.  All  candidate  tools 
were  scored  based  on  the  .same  process,  even  if  .some  were  missing  information  on 
non-essential  criteria.  Users  could  then  judge  whether  to  accept  the  output  or  revise  their 
own  inputs  based  on  the  reported  missing  information.  These  selection  repons  should  be 
provided  .so  that  they  supply  the  u.ser  with  the  context  of  how  a  decision  was  arrived  at. 
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They  should  provide  a  list  by  tool  of  characteristic  assessments  that  were  missing,  a  list 
of  tools  that  did  not  make  the  system  threshold  cutoff,  a  list  of  tools  that  did  make  the 
cutoffs,  and  a  list  of  tools  that  were  not  considered  because  they  did  not  have  an  essential 
cl.aracteristic  [24:103].  In  [24:73-103],  Lawlis  provides  a  more  thorough  discussion  of 
how  Selector  or  decision  support  logic  should  be  defined. 

Another  area  in  Selector  processing  that  was  overlooked  was  providing  the  user  with 
the  capability  of  choosing  evaluation  information  based  on  evaluator  “type”.  By 
providing  a  “type”  attribute  associated  with  an  evaluator,  a  user  can  identify  a  group  of 
evaluator  types  whose  information  is  most  valued.  For  instance,  a  non-technical 
purchaser  on  a  limited  budget  desiring  to  purchase  a  personal  computer  would  be  more 
interested  in  evaluations  of  other  non-technical  users,  since  technical  users  tend  to  have 
more  sophisticated  requirements.  Providing  for  selections  based  on  evaluator  type  creates 
another  mechanism  for  narrowing  down  the  candidate  tools  of  a  certain  SAL  Providing 
this  mechanism  will  also  help  to  address  the  area  of  design  sensitivity  to  user 
requirements. 

Summary 

This  chapter  provided  a  description  and  analysis  of  a  CASE  tool  evaluation  and 
selection  tool.  It  compared  the  ongoing  prototype  effort  of  the  STEMdB  against  goals 
established  in  the  literature.  It  used  another  prototype  called  the  ASSIST  as  a  basis  for 
comparison  since  both  tools  were  developed  towards  the  same  goals,  although  the 
ASSIST  addressed  the.se  goals  in  a  more  abstract  manner. 

Two  significant  design  omissions  or  unnecessary  restrictions  were  discovered  in  both 
the  design  methodology  and  in  the  system’s  ability  to  communicate  with  databases.  Lack 
of  a  specific  design  methodology  to  follow  and  the  Object  Oriented  problem  space 
suggests  that  the  design  be  approached  with  an  Object  Oriented  meth(xlology.  This 
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researcher  also  identified  the  need  to  use  Ada  as  the  implementation  language.  Ada 
facilitates  abstract  interface  designs  as  well  as  designs  using  good  software  engineering 
principles  and  thus  using  Ada  has  the  potential  to  make  the  system  more  maintainable, 
upgradeable  and  portable. 

Several  present  design  re-work  areas  were  identified  by  this  researcher  from  the  data 
model  and  functional  model  perspectives.  The  initial  design  was  erroneous  in  its  design 
of  the  tooLscore  relationship,  and  table  optimizations  could  be  made.  Also  the 
functionality  of  the  Formuiator,  the  Evaluator  and  the  Selector  could  be  improved  by  the 
eliminating  the  deficiencies  identified  in  this  chapter. 
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IV.  New  Approaches  to  SJEMdB  Design 


Overview 

This  chapter  will  present  two  top  level  designs  that  address  the  two  new  approaches 
identified  in  the  STEMdB  analysis  of  Chapter  III.  It  begins  by  showing  how  the  object 
oriented  design  of  the  ASSIST  (Figure  1  in  Chapter  II)  maps  to  the  parts  of  the  STEMdB 
design  (Figure  4  in  Chapter  III).  Using  the  ASSIST  framework  in  the  context  of  a 
STEMdB  system,  it  then  presents  a  top  level  STEMdB  object  oriented  design.  The 
emphasis  in  this  top  level  design  is  placed  on  the  structure  and  methods  of  interaction 
with  the  data  store.  In  particular,  this  top  level  design  emphasizes  the  Knowledge  Base 
subsystem’s  role  in  this  interaction.  The  chapter  then  concludes  by  describing  and 
applying  a  new  approach  towards  database  interface  design,  the  Structured  Query 
Language  (SQL)  Ada  Module  Extensions  (SAME).  This  method  will  be  used  in 
establishing  the  top  level  interface  design  for  the  abstract  system  interface  that  will  allow 
the  STEMdB  to  communicate  with  SQL  databases. 

Top  Level  Design  of  an  Object  Oriented  STEMdB 

For  the  reasons  stated  in  Chapter  III  the  design  of  the  STEMdB  can  be  improved  in 
two  ways,  by  redesigning  the  structure  and  dependencies  to  reflect  a  knowledge  base 
object  oriented  design  and  by  abstracting  out  the  interface  to  the  database.  A  re-design 
into  an  ASSIST-like  object  oriented  framework  is  presented  in  Figure  10.  The 
differences  between  this  design  and  the  original  ASSIST  design  result  from  the  addition 
of  the  Formulator  subsystem  and  from  the  renaming  of  the  Knowledge  Acquisition 
sub.systcm  to  “Evaluator”  and  the  Decision  Support  subsystem  to  "Selector”.  One  other 
difference  results  from  the  ASSIST  maintaining  the  databa.se  inside  of  the  Knowledge 
Ba.sc  Sub.system.  The  new  design  consists  of  a  data  store,  three  prwedural  subsystems, 
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and  two  interface  packages.  Communications  between  the  objects  in  this  design  are 
shown  by  the  directed  arrows.  Before  proceeding  with  a  more  detailed  description  of  this 
design,  the  merits  of  the  new  design  versus  the  old  are  presented. 


A  breakdown  of  the  acronym  of  the  original  design,  “stemDB”,  shows  how  the 
designers  of  this  system  placed  more  emphasis  on  the  database,  “DB”,  than  the  Software 
Tool  Evaluation  Model,  the  “stem”.  Consultations  with  the  original  designers  also 
confirmed  this  conclusion.  To  understand  how  the  new  design  emphasizes  a  knowledge 
base,  and  therefore  the  Tool  Evaluation  Model,  versus  the  original  database  emphasis. 
Figure  10  can  be  compared  to  Figure  4  and  Figure  7  (both  of  these  figures  are  repeated  on 
the  next  page  for  ease  of  reference).  From  Figure  7  and  the  design  description  of  the 
Front-End  module,  it  could  be  inferred  that  there  is  a  tight  coupling  between  the  Front- 
End  module  and  the  Database  engine.  Further,  since  there  is  no  discussion  of 
de-coupling  the  Front-End  from  the  three  subsystems  in  Figure  4,  the  design  allows  by 
omission  the  possibility  of  a  tight  coupling  between  the  three  subsystems  and  the  data 
structures  maintained  in  the  Frait-End.  Tight  coupling  among  separate  modules  in  any 
software  design  causes  the  design  to  be  less  maintainable  and  more  prone  to  errors  due  to 
the  dependencies  between  modules.  Tight  coupling  also  supports  an  environment  where 
system  state  information  can  be  dc-localizcd  and  spread  throughout  the  design.  The 
Knowledge  Ba.sc  object  oriented  approach  of  Figure  10  eliminates  the  intra-module 
coupling  by  using  well  defined  interfaces  which  provide  methods  and  types  to  calling 
modules.  The  methods  or  operations  arc  .suggested  by  the  rectangles  extending  from  the 
subsystem  box  and  the  types  arc  suggested  by  the  extended  ovals.  The  arrows  in  the 
figure  represent  communication  between  m(xlulc.s.  For  instance,  since  the  Eivaluator  and 
Selector  have  no  knowledge  of  the  information  contained  in  the  Database,  both  the 
Software  Area  of  Interest  (SAI)  identification  and  characteristic  identification  methods 
must  be  requested  of  the  Knowledge  Base  before  cither  pnxess  can  pixxccd.  With  this 
comparison  completed  tliis  chapter  will  now  discuss  the  design  in  more  detail. 
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Figure  4.  Original  Design  Components  (repeated  from  Chap  3) 
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Figure  7.  STEMdB  Basic  Components  (repeated  from  Chap  3) 
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The  processing  of  this  subsystem  and  other  subsystems  will  be  described  in  the 
following  sections  using  terms  that  are  more  generic  than  the  terms  of  the  original 
STEMdB  design.  Specifically,  the  term  “semantic  net”  and  “knowledge  frame  data”  will 
be  substituted  for  the  terms  “description  tree”  and  “node  data”,  respectively.  They  will 
also  be  used  interchangeable  with  the  terms  “structure”  and  “characteristic  data”, 
respectively.  The  justification  behind  this  switch  in  terms  is  centered  around  designing  at 
a  high  level  of  abstraction.  The  use  of  the  terms  “tree”  and  “node”  forced  the 
“implementation”  design  decision  that  the  data  would  be  organized  in  a  tree  structure  too 
early.  When  implementation  decisions  are  bound  to  the  design  too  early,  they  limit  the 
design  and  cause  the  system  to  be  less  robust  and  less  maintainable  by  tempting  designers 
to  tailor  the  design  for  a  designated  structure.  Specifically,  the  original  STEMdB  design 
was  limited  by  binding  the  system  data  structure  to  a  tree  structure.  One  limitation  that 
resulted  from  this  decision  can  be  seen  by  realizing  that  the  tree  structure  eliminated  the 
possibility  for  reuse  of  common  characteristics  by  not  allowing  multiple  parents.  By 
eliminating  this  possibility  the  design  was  not  developed  in  a  more  general  sense.  Had  it 
been  designed  in  the  more  general  sense,  then  binding  to  a  single  or  multiple  parent 
structure  would  ideally  occur  at  or  close  to  implementation  time.  By  forcing  this  decision 
at  the  end  of  the  design,  either  a  tree  structure  or  a  directed  graph  could  be  implemented. 

Design  Discussion  of  New  Formulator.  The  Formulator  Subsystem  conceptually 
exhibits  the  behavior  as  described  in  the  requirements  document  (with  the  improved 
behavior  identified  in  the  analysis  section  superseding  weaker  behaviors)  and  it  achieves 
this  behavior  using  an  object  oriented  methtxlology.  Figure  1 1  provides  a  more  detailed 
view  of  the  internal  design  of  the  new  Formulator.  It  consists  of  a  Formulator  Build 
processor  which  requires  the  resources  provided  by  the  four  resource  packages  shown. 
Resources  are  simply  methods  or  operations  and  object  types.  The  shaded  packages  arc 
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resources  tailored  to  the  Formulator  Build  Process.  Clear  packages  have  some  resources 
unique  to  the  Formulator  Process,  but  also  have  resources  that  are  common  across  all 
three  subsystem  processes,  the  Evaluator,  Selector,  and  Formulator.  There  is  the 
possibility  that  the  Present  State  resource  packages  across  all  three  systems  (see  also 
Figures  12  and  1 3)  could  share  resources  but  this  would  have  to  be  addressed  in  a  more 
detailed  design.  This  possibility  becomes  stronger  when  one  considers  the  Evaluator  and 
Selector  processors  and  their  dedicated  packages.  For  instance,  both  of  these  processes 
will  desire  state  information  about  characteristics  that  were  visited  and  altered. 

There  is  no  implied  ordering  associated  with  the  internal  sub-processes  other  than 
initial  setup  requirements  which  occur  in  the  top  two  procedure  boxes  of  the  Formulator 
and  Selector,  and  the  top  three  of  the  Evaluator. 

To  understand  how  this  processor  accomplishes  its  job,  the  following  Top-level 
Structured  English  describes  the  processing  that  the  new  Formulator  must  accomplish. 
This  section  and  all  following  processing  sections  specify  in  their  comment  areas  (which 
are  preceded  by  two  dashes)  how  the  Knowledge  Base  (KB)  subsystem  interface  aids  in 
their  processing. 

Initialize  to  Formulator_start_state; 

-  Call  KB  routine  “Initialize_KB_formulator”  through  Present  State  of  Build 

Resources  initialization  method. 

Provide  toggle  capability  to  Set_userjcvel; 

-  Call  KB  methods  “set_expert”  or ’‘scunovice”  through  initialization  re.sources. 

Provide  ability  to  open  new  or  old  Software  Area  of  Interest  (SAI); 

-  Call  KB  methods  “define_SAr’  or  “update_SAI”. 


Provide  ability  to  mark  a  description_area  as  released/not-rclcascd; 

-  Call  Build  resources  “release”  or  “imature_area”  which  will  then  call  the 
KB  routines. 
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Formulator  Build  Process 


Figure  1 1 .  Foitnulator  Internal  View 


Provide  capability  for  update  of  all  evaluations  made  prior  to  latest  release  of  an 
updated  dcscription_area; 

--  Request  KB  to  check_and_report_and_update-if_possiblc  on  any  evaluations 
using  old  description_area. 

Provide  capability  to  insert  semantic_net_description_data  and  frame  data  (or 
characteristic  data); 

--  Calls  to  the  KB  through  Characteristic  Identification  and  Association  resources 
and  Build  resources  to  request  methods:  gct_and_put_frame_data,  and 
get_and_put_semantic_net_builders 

(like  createjink,  climinatejink,  reusc_sub-scmantic_nct_stnicture, 
eliminate_sub_semantic_net_structurc). 
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Provide  capability  to  maintain  current_state  of  Formulator  process; 

--  Calls  to  KB  to  “update_present_state_sumniary”  through  Present  State  of  Build 
resources. 

Provide  capability  to  traverse_forward,  backward,  or  at  the  same_level  in  a 
semantic_net  for  review/rework; 

-  Calls  to  KB  through  Build  resources  to  request:  work_at_present_level, 

work_at_next_leveLdown/up,  show_all_not_processed/completed_frames 
go_to_not_processed/completed_frames. 

Provide  capability  to  get  a  printout  of  work  accomplished; 

-  Calls  Support  resources  for  method  “print  report”. 

Provide  ability  to  accept-partial/accept-complete/abort  the  session; 

-  Calls  KB  through  Present  State  resources  to:  Accept_session,  Abort_session, 

Check_if_semantic_net_is_completely_defined 


Design  Discussion  of  New  Evaluator .  Both  the  Evaluator  and  the  Selector  sections 
follow  the  format  of  the  Formulator  section.  The  new  Evaluator  internal  view  is  shown 
in  Figure  12.  Its  processes  and  interfaces  or  resources  are  enumerated  in  the  figure.  The 
Evaluator  Process  conceptually  exhibits  the  behavior  as  described  in  the  requirements 
document  (with  the  improved  behavior  identified  in  the  analysis  section  superseding 
weaker  behaviors)  and  it  achieves  this  behavior  using  an  object  oriented  methodology. 
To  understand  how  this  processor  accomplishes  its  job,  the  following  Top-level 
Structured  English  describes  the  processing  that  the  new  Evaluator  must  accomplish. 


Initialize  to  Evaluator_start_state; 

-  Call  KB  routine  ‘initialize_KB_evaluator”  through  Present  State  of  Evaluation 

initialization  method.  Set  Evaluator  level  to  novice 

Request  Evaluator  and  Tool  information; 

-  U.se  Evaluation  resources  to  call  *‘Get_cvaluator_data”  and  "Gct_tool_data” 

methods  from  KB. 

Identify  correct  SAI; 

-  Calls  to  the  KB  through  Characteristic  Identification  and  Association  resources 

requesting  to  provide  method  “identify_SAr’. 
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Figure  12.  Evaluator  Internal  View 


Provide  for  ability  to  toggle  Evaluator_processing_level; 

-  Novice  level,  verses  Expert  level.  Request  method  “Dcfinc_how_to_procccd‘’ 
from  KB  through  Evaluation  Resources. 

Provide  characteristics  for  evaluation; 

“  By  requesting  that  KB 

“Provide_Charactcristics_at_Evaluator_proccssing_lcvcr’  through 
Characteristic  Identification  and  Ass(x:iation  resources 
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Direct  user  on  how  to  evaluate; 

-  Request  KB  provide  method  “how_to_evaluate_characteristic”  through 

Evaluation  resources. 

Store  evaluation  data; 

-  Call  method  “Store_characteristic_info”  from  KB  through  Present  State  of 

Evaluation  process. 

Provide  ability  to  review/change  session  inputs  on  request; 

--  Call  KB  to  “provide_evaluation_process_sumniary”  through  Present  State 
Resources. 

Provide  capability  to  Accept,  Abort  or  report_on  session; 

-  Call  method  “Commit_Database”  or  “Rollback_database”  from  KB  through 

Evaluation  resources  or  call  Support  Resources  for  “provide_report”. 


Design  Discussion  of  New  Selector.  The  new  Selector  internal  view  is  shown  in 

Figure  13.  Its  processes  and  interfaces  or  resources  are  enumerated  in  the  figure.  The 

Selector  Process  conceptually  exhibits  the  behavior  as  described  in  the  requirements 

document  (with  the  improved  behavior  identified  in  the  analysis  section  superseding 

weaker  behaviors)  and  it  achieves  this  behavior  using  an  object  oriented  methodology. 

To  understand  how  this  processor  accomplishes  its  job,  the  following  Top-level 

Structured  English  describes  the  processing  that  the  new  Selector  must  accomplish. 
Initialize  to  Selector_start_state; 

“  Call  KB  routine  “InitiaIize_KB_selector”  through  Pre.scnt  State  of  Choices 
initialization  method.  Set  Selector  level  to  novice 

Identify  correct  SAI; 

-  Calls  to  the  KB  through  Characteristic  Identification  and  Association  resources 

requesting  to  provide  method  “identify_SAI” 

Provide  for  ability  to  toggle  Selector_processing_level; 

-  Novice  level  verses  Expert  level,  Reque.st  method  “Dcfinc_how_to_procccd” 

from  KB  through  Present  State  of  Choices  Resources. 

Provide  characteristics  for  selection; 

-  By  requesting  that  KB 

“Provide_Characteristics_at_Selector_proccssing_lcvcl’'  through 
Characteristic  Identification  and  Association  resources 

Direct  user  on  how  to  go  through  selection  process; 

-  Request  KB  provide  methtxl  “how_to_pr(x:ced”  through  Support  resources. 
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Figure  13.  Selector  Internal  View 


Store  selection  weights  data; 

-  Call  method  “Store_characteristic_wcightJnfo”  from  KB  through  Present 

Slate  of  Selection  process. 

Provide  ability  to  score  tools ; 

-  Call  KB  to  “Scorejools”  through  Present  State  Resources. 

Provide  ability  to  review  session  inputs  on  request; 

-  Call  KB  to  “provide_selection_pr(x;ess_summary”  through  Present  State 

Resources. 
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Provide  ability  to  re-accomplish  selected  weights  and  criteria  to  achieve  different 
results; 

-  Call  KB  to  “reset_cutoff_threshold”,  re-accomplish  criteria  or 

re-define_essential_characteristic  processing  through  Manipulation  of 
Results  Resources. 

Provide  capability  to  Accept,  Abort  or  report_on  session; 

-  Call  method  “Commit_Database”  or  “Rollback_database”  from  KB  through 

Manipulation  of  Results  resources  or  call  Support  Resources  for 
“provide_report”. 


FunctionoHty  of  Rest  ofOOD  Design .  With  the  system  processors  defined  all  that  is 
left  to  describe  is  the  functionality  of  all  remaining  interfaces  (see  Figure  10).  The  usual 
functions  are  provided  by  the  User  Interface  resources  and  the  SQL  Interface  resources. 
The  User  Interface  provides  all  resources  necessary  to  provide  and  acquire  information 
to/from  a  STEMdB  user.  The  SQL  interface  provides  all  resources  necessary  to  store, 
update  and  retrieve  information  from  a  commercial  database.  The  Knowledge  Base 
interface  provides  all  methods  and  types  that  a  processor  must  have  to  operate  with  the 
system  data’s  structure  and  content.  It  provides  the  functionality  of  creating  structures  in 
the  database  to  store  system  data  and  it  provides  resources  to  store  and  retrieve  system 
data  from  the  database.  It  provides  the  resources  to  maintain  a  running  summary  of  what 
characteristics/structures  were  accc.ssed  and  how  they  were  modified.  It  provides  the  raw 
scores  (quality  and  functionality)  of  tools  to  the  Selector  (the  Selector  maintaining  its 
own  cutoff  threshold  and  top  level  weights  accomplishes  further  pr(x:essing  on  this  data). 
It  provides  the  build  resources  to  the  Formulator  and  it  provides  the  insert  and  delete 
characteristic  data/weights  resources  to  the  Selector  and  Evaluator.  It  provides  all 
characteristic  viewing  resources  and  all  structure  traversal  resources  to  all  processors. 
Specific  viewing  resources  are  implemented  within  each  prix-’cssor  under  the  Support 
Resources  Package. 
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Top  Level  Design  of  an  Abstract  System  Interface  to  an  SQL  Database 

Chapter  III  established  that  STEMdB  portability  and  maintainability  were  hindered 
by  dependence  on  one  commercial  database  and  it  identified  the  need  to  design  the  entire 
STEMdB  in  Ada.  To  make  the  STEMdB  independent  of  any  database  an  abstract 
interface  needed  to  be  created  and  incorporated.  Hidden  complications  always  seem  to 
arise  when  one  tries  to  create  an  interface  from  one  application  to  another,  however.  For 
instance,  in  creating  an  interface  between  the  two  procedural  languages  Ada  and  C,  a 
binding  designer  must  understand  the  design  foundations  of  both  languages  and  he/she 
must  create  conversion  routines  to  avoid  conflicts  that  arise  from  design  differences.  One 
example  of  a  design  difference  between  Ada  and  C  is:  C  has  null  terminated  character 
strings  and  Ada  does  not.  Creating  a  binding  or  interface  between  a  procedural  language 
like  Ada  and  a  non-procedural  or  data  oriented  language  like  SQL  complicates  interface 
designs  even  more.  Extensive  work  has  already  been  accomplished  towards  identifying 
these  complications,  and  a  model  complete  with  template  resources  was  developed  to 
address  this  exact  type  of  interface  development.  This  model  and  the  methods  associated 
with  it  are  called  the  SAME  fl7).  The  SAME  is  a  binding  or  interface  between  Ada  and 
SQL  that  allows  both  Ada  and  SQL  to  accomplish  their  jobs  without  compromising  each 
other’s  design  foundations,  while  at  the  same  time  allowing  Ada’s  abstraction 
mechanisms  to  overcome  some  of  SQL’s  shortcomings.  It  allows  for  the  safe  treatment 
of  SQL  null  values  and  it  makes  extensive  use  of  the  Ada  exception  mechanism. 

Problems  Addressed  by  the  SAME.  Before  proceeding  on  with  an  overview  of  the 
SAME  mcthcxl,  it  may  help  to  understand  the  interfacing  problems  it  was  developed  to 
overcome.  Graham  in  ( 17: 171  identified  five  problems  specific  to  Ada  to  SQL  bindings 
that  his  model  the  SAME  addresses.  Those  five  areas  were: 
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1 .  Typing  model  differences  between  Ada  and  SQL  -  The  major  difference  between 
typing  models  is  that  Ada  has  an  abstract  typing  capability  while  SQL  does  not.  In  fact, 
SQL  is  in  the  opposite  end  of  the  spectrum  when  compared  with  a  robust  typing  model 
since  it  operates  on  a  limited  set  of  types. 

2.  Treatment  of  null  values  -  Ada  works  only  in  a  two  valued  logic  world  where 
SQL  uses  three  valued  logic.  For  instance,  SQL  provides  logical  operations  that  expect 
variables  to  be  in  the  form  of  “true,  false,  or  null”.  Ada  can  only  logically  operate  on 
variables  that  are  either  true  or  false. 

3.  String  Processing  -  SQL  pads  strings  with  blanks,  and  its  character  sets  are 
database  implementation  defined.  Ada  uses  the  predefined  character  set  called  ASCII  for 
package  standard  operations. 

4.  Decimal  Fixed  Point  Arithmetic  -  The  operations  on  decimals  in  both  Ada  and 
SQL  work  differently.  SQL  implementations  store  decimals  in  a  packed  machine  format, 
Binary  Code  Decimal  (BCD),  which  Ada  docs  not  recognize. 

5.  Types  defined  outside  of  the  SQL  standard  -  Commonly  used  types  such  as  the 
Date  type  are  important  to  model  yet  they  are  implemented  in  different  ways.  Graham 
also  identifies  the  need  to  be  able  to  store  enumerated  types  in  SQL  when  SQL  does  not 
support  an  SQL  enumeration  type. 

This  research  will  use  the  SAME  nuxlcl  to  overcome  all  problems  identified  in  this 
listing.  It  will  be  presented  as  a  top-level  design,  however,  and  solutions  to  some  of  thc.se 
problems  may  not  be  obvious  until  a  more  detailed  level  design  is  accomplished.  With 
this  justification  complete,  an  ewerview  of  the  SAME  mctlKxl  and  a  STFtMdB  interface 
design  using  the  SAME  can  be  presented. 

Overview  of  How  to  Apply  the  SAME  Method.  Graham  builds  the  SAME  mctlnxl 
from  the  bottom  up.  He  builds  his  abstract  intcil'acc  based  on  primitives  he  calls  abstract 


domains.  An  abstract  domain  in  the  SAME  model  is  identified  by  a  unique  name  given 
to  a  column  name  in  a  table.  The  common  sense  rule  that  designers  must  incorporate 
when  creating  these  abstract  domains  is:  if  two  distinct  columns  represent  the  same  type 
of  information  and  they  can  be  compared  to  each  other,  then  their  abstract  domains  are 
the  same.  Graham  uses  the  example  of  one  application  having  two  distinct  tables  in 
which  each  has  a  “city”  attribute  or  column  name.  Since  they  both  represent  the  same 
abstract  domain  only  one  domain  primitive  is  defined,  and  it  is  named  “CITY”.  [17:8-10] 
Once  these  column  name  equivalents  are  identified  they  are  associated  with  two 
types,  a  null  bearing  and  not  null  bearing,  and  all  the  methods  that  operate  on  those  types. 
This  association  is  necessary  to  model  SQL  null  values  in  Ada  and  to  define  specific 
types  that  represent  SQL  attribute  objects.  In  general,  this  association  occurs  as  a  two 
step  process.  First  the  null  bearing  type  for  a  given  column_name  is  assigned  the  name, 
“column_name_Type”  and  the  not  null  bearing  type  for  the  same  column_name  is 
assigned  the  name  “column_namc_Not_NuH”.  Then  these  names  are  used  to  create  an 
Ada  derived  type  that  is  based  on  the  SAME  standard  package  that  maps  to  the  correct 
type  of  SQL  domain.  An  instantiation  of  a  generic  operations  package  along  with  the.se 
derived  types  produces  a  Domain  Primitive  Ab.stract  Type.  Figure  14  shows  these 
building  block  abstract  domains  as  "Domain  Primitive  Abstract  Types”.  This  figure  is 
presented  to  clarify  the  foundation  upon  which  the  SAME  typing  model  is  built.  The  way 
Graham  builds  this  typing  model  is  through  the  use  of  "Ada  Derived  Types”.  Using  a 
derived  type  in  Ada  creates  a  new  base  type.  In  Figure  14  the  Concrete  Types  and  the 
Domain  Primitive  Abstract  Types  are  derived  from  their  foundational  types.  A 
foundational  type  in  Figure  14  is  the  type  immediately  below  a  given  type  (for  instance. 
SQL-Based  Prc-Dcfincd  Types  arc  the  foundational  type  of  Concrete  'I'ypcs).  The 
package  called  SQL_Standard  defines  "SQL  Based  Prc-Dcfincd  'lypcs”  as:  Char, 
Smallint,  Int,  Real,  Doublc_Prccision,  Decimal,  SQL_code_Typc.  SciLEiror,  Not_Found 
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and  Indicator_Type.  It  defines  the  majority  of  these  types  by  placing  database 
implementation  tailored  constraints  on  Ada  predefined  types.  As  an  example.  Type 
SQL_Standard.Int  is  defined  in  the  following  way;  type  Int  is  range  bi..ti;.  The  place 
holders  “bi”  and  “ti”  are  the  actual  integer  upper  and  lower  limits  defined  by  the  database 
implementation.  These  actual  limits  have  to  be  inserted  in  place  of  “bi”  and  “ti”  when 
installing  the  SAME  resources.  The  Concrete  Types  are  then  built  on  top  of  these  SQL 
Based  Types  by  defining  derived  types  and  operations  for  each  of  the  basic  pre-defined 
type  equivalents.  The  following  is  a  listing  of  packages  that  define  these  Concrete  Types: 
SQL_Char_Pkg,  SQL_SmallInt_Pkg,  SQL_Int_Pkg,  SQL_Real_Pkg, 
SQL_Double_Precision_Pkg,  SQL_Decimal_Pkg.  Appendix  B  has  a  complete  copy  of 
the  SAME  supplied  package  specification  resources  discussed  in  this  research 
[17;  143-248].  It  is  not  the  intention  of  this  research  to  describe  how  to  set  up  the  SAME 
environment  but  rather  how  to  apply  it.  The  reader  is  directed  to  [17]  for  details. 

With  all  of  this  typing  information  understood  (with  the  exception  of  Composite 
Domain  Types  which  will  be  explained  within  the  next  few  paragraphs),  it  is  now 
important  to  present  an  example  relative  to  the  STEMdB  of  how  to  define  a  domain 
primitive  type.  To  set  up  the  abstract  domain  primitive  type  for  TOOLJD  the  following 
package  would  have  to  be  created: 
with  SQL_Int_Pkg; 
package  Tool_id„primitive_domain  is 
type  TOOL_ID_Not_NuII  is  new  SQL_lnt_Pkg.SQL_Int_Not_Null; 
type  TOOL_lD_Type  is  new  SQL_Int_Pkg.SQL_Ini; 
package  TOOL_ID_Ops  is  new 

SQLJnt_Pkg.SQL_InLOps(TOOL_lD_Type,  TOOL_ID_Not_Niill); 
end  T(X)l_id_primitivc_domain; 
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;  ;  ;  Composite  Domain  Types  •  • 

Domain  Primitive  Abstract  Types 

_ _ _ r 

Concrete  Types 


SQL  Based  Pre-Defined  Types 


Basic  Ada  Pre-Defined  Types 


Figure  14.  SAME  Foundational  Type.s 


All  primitive  abstract  domain  dependent  operations  are  defined  by  the  instantiation 
of  the  “SQL_*_Pkg.SQL_*_OPS(...)”  generic  packages  (where  represents  a  wildcard 
placeholder  and  in  the  above  example  it  would  take  on  the  value  "Int”),  all  other 
operations  are  inherited  from  the  derived  type's  domain.  These  primitive  dependent  type 
operations  define  how  to  get  a  null  type  given  a  not_null  type  and  vice  versa  .  They  also 
define  “Assign”  operations  for  the  limited  private  types  which  define  all  null  bearing 
types.  For  instance,  TOOL_ID_Typc  is  a  limited  private  type  which  could  not  be 
assigned  if  an  assign  operation  was  not  defined  for  it.  U.sc  of  the  limited  private  types  to 
define  a  null  bearing  type  is  necessary  since  a  null  bearing  type  is  a  two  component 
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record  that  contains  a  not  null  bearing  type  and  a  Boolean  that  represents  whether  the 
record’s  contents  are  null  or  not.  At  any  given  time  if  the  record’s  state  (as  determined  by 
the  null  component)  is  not  null  then  the  contents  of  its  value  part  component  are  valid, 
otherwise  the  contents  are  invalid. 

The  goal  of  all  of  these  building  block  types  and  operations  is  to  support  the  creation 
of  the  “Composite  Domain  Types”  shown  in  Figure  14.  These  composite  domain  types 
are  simply  combinations  of  domain  primitive  types  that  together  represent  .some  object  in 
an  abstract  interface.  These  composite  types  arc  usually  defined  by  a  record  structure 
containing  the  primitive  types.  The  operations  associated  with  that  record  structure,  once 
defined,  complete  the  definition  of  an  ab.stract  interface  to  an  “SQL  implementation 
module”. 

It  is  important  at  this  point  to  diverge  and  explain  how  an  SQL  implementation 
module  can  be  built.  Since  there  were  no  known  .standard  SQL  module  compilers 
available  at  the  time  of  this  research,  a  substitute  mcthtxl  for  producing  SQL  module 
resources  had  to  be  found.  The  .substitute  method  chosen  was  to  create  database 
supported  SQL  modules  by  implementing  an  SQL  mcxlule  using  the  embedded  SQL  calls 
within  a  supported  language  framework.  This  would  require  creating  another  interface 
between  Ada  and  the  database  supported  interface  language  in  order  to  call  mtxlules  in 
that  language.  For  example,  the  Oracle  Database  for  the  Macintosh  supports  embedded 
SQL  calls  from  within  the  framework  of  a  C  program  |2.5|.  Meridian  Ada  for  the 
Macintosh  suppons  pragma  interface  calls  to  Macintosh  Programers 
Workshop  C  (MPW  C)  object  libraries.  To  implement  an  abstract  interface  Ixjtwccn 
Meridian  Ada  and  Oracle  on  the  Macintosh.  MPW  C  resources  would  have  to  l)c  built 
using  database  supplied  embedded  SQL  rc.sourccs.  These  rcstnirces  would  then  have  to 
be  pre -compiled  and  compiled  l)cforc  the  b(xly  «)f  the  Ada  abstract  interface  would  lx: 
able  to  call  them  using  a  newly  designed  MPW  C  interface  and  an  Ada  Pragma  Interface. 


Since  the  goal  of  this  research  is  to  define  an  abstract  interface  for  an  Ada  to  SQL 
binding,  the  details  of  the  bodies  of  those  abstract  interfaces  (which  are  implementation 
issues  not  top  level  design  issues)  will  not  be  described  other  than  to  describe  an  example 
of  their  general  structure  and  desired  behavior. 

It  is  now  time  to  take  another  look  at  the  definition  of  a  SAME  abstract  interface  or 
binding,  and  the  operations  that  make  up  that  definition.  Graham  emphasizes  that 
application  logic  should  never  enter  into  the  definition  of  an  abstract  interface’s 
operations.  He  then  states  that  application  logic  should  be  built  at  least  one  layer  above 
the  abstract  interface.  This  is  sound  design  'ice  since  the  design  Oi  the  interface  has 
the  single  goal  of  communicating  with  a  database.  Graham  also  emphasizes  that  the 
database  should  be  allowed  to  accomplish  the  operations  that  it  is  best  suited  for  while  the 
body  of  the  abstract  interface’s  main  goal  should  be  to  work  as  a  translator.  In  general, 
the  operations  that  are  defined  in  the  abstract  interface  mimic  those  that  must  be  called  to 
manipulate  a  structure  or  table  in  a  database.  These  operations  can  be  single  record  based 
and  called  by  defining  SQL  procedure  cr.ll  interfaces  or  they  can  be  “cursor  based”. 
[17:59] 

Cursor  based  calls  are  the  mechani...n  that  allows  an  application  to  work  with 
multiple  record  retrievals.  A  cursor  is  defined  in  SQL  as  a  group  of  records  (defined  by 
the  cursor’s  SQL  statement)  that  can  be  opened,  stepped  through  with  a  fetch  operation, 
and  closed.  A  Cursor  is  defined  by  its  cursor  declaration  which  contains  exactly  one  SQL 
statement.  The  Cursor  becomes  visible  to  the  application  only  after  it  is  opened,  and  it 
can  only  be  operated  on  within  a  nmning  application  while  it  is  opened.  A  cursor  can 
only  be  stepped  through  in  one  direction,  the  only  way  to  return  to  a  previously  fetched 
record  is  to  close  and  re-open  the  cursor.  A  database  can  have  multiple  cursors  opened  at 
the  same  time  and  these  cursors  can  be  identified  by  their  cursor  names. 


73 


Graham  identifies  all  possible  basic  database  operations  or  SQL  statements  that  may 
need  to  be  modeled  in  the  abstract  interface  in  [17:60].  Table  3  provides  this  list  along 
with  an  identifier  column  which  classifies  whether  the  type  of  statement  is  a 
transaction  (T),  a  cursor  (C)  or  a  non-cursor  (NC).  According  to  Date  in  [15:48-49] 
transactions,  cursors  and  non-cursors  are  the  three  classifications  that  all  SQL 
manipulative  statements  fall  into.  The  “Ada  Parameter  Kinds”  column  lists  two  types  of 
parameters  which  the  Abstract  interface  will  use  when  making  calls  to  an  SQL  module. 
Graham  defines  the  “row  record”  as  an  object  of  the  Composite  domain  type  and  the 
“individual  parameters”  as  objects  of  Domain  primitive  types.  He  explains  that  the 
individual  parameters  will  be  used  mostly  when  an  interface  designer  must  model  SQL 
“having”  or  “where”  clause  information.  Both  of  these  clauses  are  used  in  SQL  to  qualify 
the  type  of  data  desired.  The  “where”  clause  is  used  to  eliminate  rows  in  non-grouped 
select  statements,  the  “having”  clause  is  used  to  eliminate  rows  in  the  “group  by”  select 
statements  [15:95]. 

The  last  area  that  needs  to  be  addressed  before  presenting  a  design  of  the  abstract 
interface  of  the  STEMdB  using  the  SAME  framework  is  how  the  body  of  the  interface  is 
expected  to  behave.  There  are  four  behavioral  requirements  that  this  implementation 
must  meet.  It  must  convert  any  inputs  to  an  SQL  module  from  Abstract  domain  primitive 
types  to  SQL_Standard  types,  it  must  call  the  SQL  module,  it  must  convert  all  necessary 
outputs  of  an  SQL  module  back  to  Abstract  domain  primitive  types  and  it  must  perform 
error  checking  using  both  SQL  indicator  parameters  and  the  Sqlctxle  parameter. 

Indicator  parameters  in  SQL  arc  used  to  indicate  if  a  fetched  field  is  null  (the  indicator  is 
a  Boolean  that  is  .set  to  true  when  nothing  matches  the  database  call’s  criteria).  Sqlcodc 
parameters  are  used  to  indicate  implcmcnter  defined  database  errors  ass(x:iatcd  with 
database  operations.  [17:621 


74 


Table  3,  SQL  Statement  to  Ada  Mappings 


Type 

SQL 

Ada  Parameter 

Mode 

Statement 

Kinds 

C 

close 

none 

T 

commit 

none 

C 

positioned 

delete 

none 

NC 

searched 

delete 

Individual 

Parameters 

in 

C 

fetch 

row  record 

in,  OUT 

NC 

insert 

(values) 

row  record 

in 

NC 

Individual 

Parameters 

in 

C 

open 

Individual 

Parameters 

in 

T 

rollback 

none 

NC 

select 

row  record  & 
Individual 

Parameters 

in,  OUT 
in 

C 

Individual 

Parameters 

in 

NC 

Individual 

Parameters 

in 

LEGEND 

C  =  Cursor  Operation 

NC  =  Non-cursor  Operation 

T  =  Transaction  Operation 

STEMdB  Abstract  Interface  Design  Using  SAME.  Accomplishing  the  design  of  the 
abstract  interface  was  a  three  step  pr(x;ess.  The  first  step  involved  defining  the 
arehitectiire  of  the  domain  primitive  types,  the  second  involved  identifying  basic  database 
operations  that  each  of  the  three  STEMdB  processes  would  need  to  accomplish  its  job. 
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and  the  third  involved  identifying  the  composite  domain  types,  individual  parameters  and 
associated  operations  that  would  support  these  higher  level  STEMdB  operations. 

During  this  process  it  became  obvious  that  the  STEMdB  could  not  be  feasibly 
designed  without  utilizing  the  additional  SQL  methods  and  types  associated  with 
dynamic  SQL2.  SQL2  is  an  extension  standard  that  was  being  developed  in  1989  to 
address  areas  where  the  SQL  standard  was  weak  or  lacking  117].  The  STEMdB  design 
requirement  that  the  user  be  allowed  to  randomly  select  anywhere  from  one  to  eleven 
desired  attributes  to  narrow  down  tool  selection  candidates  [19: 17]  was  the  deciding 
factor  for  studying  a  dynamic  approach.  This  requirement  would  force  a  static  SQL 
design  to  provide  one  select  operation  for  every  possible  combination  of  all  eleven  inputs. 
This  would  mean  that  2048  operations  would  have  to  be  designed  and  supported.  To 
avoid  this  unnecessary  coding,  the  dynamic  SQL2  design  addressed  by  Graham  was  used. 
[17:117-125] 

Graham  presented  two  methods  for  approaching  a  dynamic  design.  Both  methods 
were  based  on  the  “<dynamic  using  de.scription  area  stnicture>  or  SQLDA”  [17:1 15]. 
This  structure  supports  a  buffered  approach  that  many  databases  use  to  dynamically 
communicate  with  application  programs.  Graham  asserted  that  the  two  methods  differed 
in  their  visibility  of  the  SQLDA  structure  from  an  application  program’s  perspective. 

The  first  method  duplicated  the  SQLDA  structure  on  the  abstract  interface  side,  and  the 
second  method  applied  a  functional  approach  which  hid  the  details  of  the  SQLDA  on  the 
database  module  side.  The  overhead  associated  with  the  "visible”  methcxl  was 
considered  to  be  too  much  by  Graham,  .so  he  advocated  the  functional  methcxl.  His 
arguments  about  duplication  of  data  and  multiple  transformations  slowing  down  an 
interactive  session  were  well  founded  and  the  functional  approach  was  used  in  parts  of 
the  STEMdB  abstract  interface  design. 
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The  functional  approach  to  dynamic  SQL2  required  two  additional  resource 
packages,  SQL_Standard_Dynamic  and  SQL_Dynamic_Pkg,  copies  of  which  reside  in 
Appendix  B.  The  assumptions  made  to  simplify  this  approach  were  the  same  ones  used 
in  Graham’s  example  in  [17:124];  only  one  dynamic  statement  would  be  in  use  at  any 
given  time  and  its  contents  would  be  available  in  an  object  called  STMT  of 
SQL_Char_Not_Null  type.  There  were  two  top  level  functionalities  that  needed  to  be 
provided  by  a  dynamic  interface.  First  the  interface  had  to  allow  for  the  set  up  of  desired 
statement  instantiations  and  then  it  had  to  provide  for  operating  on  those  instantiations 
using  parameter  type  knowledge. 

Before  proceeding  with  the  overall  design  discussion,  the  actual  process  of  using  a 
dynamic  interface  will  be  presented.  This  should  help  the  reader  to  understand  why 
ce  rtain  functions  and  procedures  must  be  provided  by  the  dynamic  interface.  The  process 
that  had  to  be  followed  from  an  application  standpoint  using  [17:12'^-125]  as  a  guideline 
was:  prepare  the  STMT,  allocate  a  name  for  both  input  and  output  SQLDA  processing 
while  associating  a  maximum  number  of  parameters  with  each  name,  create  the  link 
between  these  names  and  the  prepared  STMT  by  calling  a  Describe  function,  provide  a 
get_parametcr_count  function  that  operates  on  a  SQLDA  name,  and  use  this  function  to 
check  if  there  are  any  input  parameters  (this  is  all  based  on  the  Describe  function  using 
the  prepared  statement  as  a  template  for  building  an  SQLDA  instantiation  complete  with 
parameter  types  that  arc  waiting  to  be  filled  with  objects).  If  there  arc  inputs,  step 
through  each  input  parameter  and,  using  a  gct_paramctcr_typc  function,  obtain  the 
parameter’s  type.  Then  u.sc  the  type  in  a  “case”  statement  to  pick  the  correct 
sct_paramcter_valuc  function  to  insert  the  dynamic  SQLdata  object  into  that  parameter 
(the  dynamic  SQLdata  object  is  obtained  from  the  user  as  a  criterion  that  is  desired  to 
hold  true  for  that  parameter).  Once  all  inputs  are  pnx’cssed  begin  output  prtxessing.  Use 
the  same  get_parameter_count  function  to  discover  how  many  output  parameters  there 
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are  in  the  Output_SQLDA  object.  If  there  are  zero  outputs  then  it  is  not  a  select 
operation,  so  execute  it.  If  there  are  outputs,  open  a  cursor  that  is  associated  with  the 
Input_SQLDA  and  process  the  cursor  with  associated  Fetch  ,  Get_parameter_type  and 
Get_SQLdata  functions  (which  are  selected  based  on  the  SQLType  retrieveay  then  close 
the  cursor.  All  of  this  processing  can  be  accomplished  if  the  dynamic  abstract  interface 
provides  the  eleven  procedures/functions  identified  in  Table  4. 

Table  4.  Functions  Provided  by  an  Abstract  Dynamic  Interface 

_ PrepareQ _ 

_ AllocateQ _ 

_ Describe_Input() _ 

_ Describe_output() _ 

_ Get_Nuniber_parameters() _ 

_ Get_parameter_type() _ 

_ Set_parameter_value() _ 

_ Get_paramter_value() _ 

_ Open_Cursor() _ 

_ FetchQ _ 

_ Clo.se() _ 


With  the  discussion  of  dynamic  interface  considerations  complete,  the  overall  design 
approach  can  now  be  presented.  The  design  will  be  described  in  the  context  of  three 
layers,  the  Primitive  layer,  the  Database  intelligent  layer,  and  the  Application  intelligent 
layer.  A  description  of  all  of  these  layers  will  be  provided  as  the  design  discus.>ion 
progresses. 
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Instead  of  having  each  of  the  lowest  level  domain  primitive  abstract  types  as  a 
package,  this  researcher  decided  to  group  types  into  entity  level  packages.  This  helped  to 
reduce  the  number  of  domain  primitive  packages  that  would  need  to  be  “withed”  or  made 
visible  for  both  further  abstract  interface  design  and  application  program  design.  It  also 
encapsulated  entity  and  relationship  information.  All  non-trivial  relationships  attributes 
were  also  grouped  into  their  own  domain  abstract  primitive  type  packages.  Whenever 
relationships  had  “foreign  keys”  .which  are  keys  inherited  from  connected  entities,  the 
keys  would  already  be  defined  in  the  connected  entity’s  domain  primiti  /e  definition  (i.e., 
they  were  not  re -defined  in  the  relationship  domain).  Any  operation  that  worked  on  a 
relationship  domain  would  have  to  “with”  all  appropriate  connected  entity  domains  along 
with  the  relationship  primitive  domains.  For  instance,  a  formulator  operation  of  linking  a 
domain  with  a  GSC  would  require  an  update  to  the  root_node  table  which  would  require 
an  operation  on  the  domain  primitive  types  defined  in  the  root_node.  There  are  no 
primitive  types  defined  for  the  root_node  relationship  because  all  attributes  are  foreign 
keys  and  they  are  already  defined  in  the  connected  entities  domain  primitive  type 
definitions.  The  update  operation  would  have  to  have  visibility  to  both  The_Arca  and  the 
GSC  domain  primitive  types.  The  domain  primitive  type  packages  arc  defined  in 
Appendix  C.  To  clarify  how  each  attribute  contributes  to  this  package,  each  attribute’s 
information  is  consolidated  in  one  area  which  is  separated  from  other  attribute 
information  areas  by  a  blank  line.  To  implement  these  packages  all  generic 
“SQL_*_Pkg.SQL_*_OPS(...)”  packages  must  be  moved  to  the  end  of  each  entity 
package  since  they  arc  later  declarative  items  (later  declarative  items  arc  defined  in  the 
Ada  Language  Reference  Manual). 

One  more  design  grouping  of  ab.stract  domain  primitive  types  was  considered.  By 
looking  at  the  highlighted  entities  and  objects  in  Figures  15, 16  and  17  (Note:  When 
possible,  these  figures  reflect  the  design  changes  advocated  in  Chapter  III;  for  instance 
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the  the  linkST  relation  is  replaced  by  the  linkSAWT  relation.)  one  realizes  that 
application  programs  responsible  for  altering  the  state  of  the  highlighted  entities  and 
relationships  will  be  written  for  each  of  the  three  subsystems.  Therefore,  the  Ada 
package  could  be  used  to  group  the  domain  primitive  abstract  type  packages  that  were 
created  from  the  highlighted  entities  and  relationships  into  three  disjoint  packages.  It  was 
decided  that  this  design  encapsulation  would  be  better  utilized  in  a  layer  of  abstract 
interface  that  is  built  on  top  of  the  primitive  interface  to  the  database  (which  is  being 
derived  now).  For  clarification  purposes  this  new  blanket  layer  will  be  called  the 
“Database  intelligent  layer”.  The  Database  intelligent  layer  design  is  discussed  in 
concept  at  the  end  of  this  section  but  is  not  addressed  any  funher  by  the  design  since  it  is 
more  detail  than  the  top  level  design  of  this  chapter  required.  A  top  level  interface  design 
in  the  sense  of  this  chapter  answers  the  question:  “what  is  the  minimum  required  to  get 
the  interface  to  the  database  defined  without  bringing  in  application  logic?”. 

To  streamline  access  to  domain  primitive  types,  the  idea  of  placing  composite 
methods  built  on  domain  primitive  types  into  the  same  entity  packages  that  encapsulated 
tho.se  types  was  considered.  Trying  to  place  composite  mcthtxls  into  packages  that  also 
defined  their  foundation  types  meant  that  composite  types  (or  records)  and  procedures 
would  have  to  be  declared  based  on  primitive  types  that  were  not  fully  defined.  This 
would  be  true  because  the  instantiation  of  generic  packages 
"SQL_*_Pkg.SQL_=*’_OPS(...)”  is  a  “later_declarative_item”  according  to  the  Ada 
language  referenee  manual  and  it  must  be  defined  after  all  basic  declaration  items.  Since 
attempting  this  would  violate  the  rules  of  Ada  and  would  not  work,  this  idea  was  aborted. 

A  better  .solution  places  the  composite  operations  into  entity  packages  that  mirrored 
their  foundational  domain  primitive  type  entity  packages.  The  basic  behavior  that  all  of 
thc.se  packages  would  provide  would  be  in  the  form  of ‘’inserting,  updating,  deleting, 
searching  and  retrieving”  objects  of  attribute  types  ami  composite  record  types.  In 


SO 


addition  to  these  composite  operation  packages  which  would  be  entity  specific,  two 
additional  packages  would  be  required,  one  to  model  dynamic  interfaces  and  one  to  work 
on  database  transactions.  Neither  of  these  two  additional  packages  would  provide 
operations  based  on  a  single  entity  or  relationship,  yet  operations  they  contained  would 
be  necessary  to  complete  a  definition  of  the  primitive  layer.  This  justifyed  encapsulating 
these  operations  in  their  own  packages.  Specifications  for  all  of  these  packages  are 
located  in  Appendix  D. 

Before  continuing  on  with  a  description  of  the  design,  it  is  necessary  to  first  define 
the  difference  between  logical  packages  and  physical  packages  in  the  context  of  this 
document.  A  physical  package  is  what  would  actually  be  coded  as  an  Ada  package  by  an 
implementer.  A  logical  package  allows  information  to  be  grouped  so  that  the  concepts 
explained  in  this  design  are  more  easily  understood.  Physically,  the  logically  grouped 
packages  would  still  remain  separate  and  distinct  packages.  One  other  concept  that  needs 
explaining  is  the  idea  of  having  “view  packages”.  Essentially  a  view  package  provides 
all  top  level  knowledge  base  operations  and  types  to  its  respective  sub.system  (All  view 
packages  taken  together  represent  the  Application  intelligent  layer.) .  It  operates  similar 
to  the  way  views  operate  in  database  applications.  It  gives  the  calling  subsystem  the 
minimum  information  needed  to  get  the  job  done  while  hiding  the  details  of  the 
operations  and  types. 

With  the  basic  building  bl(x:ks  established  and  an  explanation  of  views  and  logically 
grouped  packages  complete,  the  perspective  of  how  this  all  fits  in  with  aii  object  oriented 
STEMdB  design  can  now  be  presented.  First,  each  domain  primitive  lyfx;  package  and 
composite  operation  package  that  operates  on  the  same  entity  or  relation  is  logically 
grouped  into  one  package  that  is  defined  by  the  entity’s  name.  All  logically  grouped 
entities  conjoined  with  the  transactions  and  dynamic  packages  represent  the  Primitive 
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layer.  This  Primitive  layer  is  the  foundation  upon  which  the  Database  intelligent  layer  is 
built. 
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Figure  15.  Formulator  Altered  Objects 
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Figure  16.  Evaluator  Altered  Objects 
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Figure  17.  Selector  Altered  Objects 


The  Database  intelligent  layer  can  be  separated  into  three  distinct  physical  packages 
(justification  for  this  approach  was  introduced  earlier  in  this  section)  which  each 
encapsulate  operatit)ns  that  work  on  entities  belonging  to  a  group.  The  entity  groupings 
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are  associated  with  the  state  altering  behavior  of  the  calling  subsystems.  Any  entity  that 
can  be  physically  altered  by  a  calling  subsystem  has  Database  intelligent  layer  operations 
defined  in  a  package  that  is  named  after  that  subsystem.  For  instance,  the  Formulator  can 
alter  the  states  of  the  General  Software  Characteristic,  the  linkGG,  the  root_node  and 
The_Area  entities  and  relationships  (see  Figure  15),  so  the  operations  for  these  objects 
are  located  in  the  Formulator  Altered  Grouping  package  which  is  contained  within  the 
Database  intelligent  layer.  Next  level  non-state  altering  operations  for  these  entities  arc 
co-located  in  the  same  package.  Figure  18  shows  how  this  composite  build  process 
would  be  accomplished  for  Formulator  State  Alteration  considerations  (the  Evaluator  and 
Selector  considerations  would  be  built  using  the  same  method).  Essentially  the  single 
overall  desired  behavior  of  the  Database  intelligent  layer  is  to  provide  the  database 
application  operations  that  use  the  re.sources  provided  within  the  Primitive  layer.  For 
instance,  to  acquire  all  GSCJD’s  for  a  given  SAI,  the  Database  intelligent  layer  would 
know  only  how  to  open  a  cursor,  step  through  a  loop  which  calls  a  fetch_gcs_ID 
operation  in  the  Primitive  layer  and  clo.se  that  cursor  when  done.  It  would  know  when 
the  fetch  operation  is  complete  by  using  a  Boolean  check  that  is  updated  on  each  fetch  by 
the  Primitive  layer. 

The  more  .sophisticated  or  complex  interface  logic  occurs  at  the  “view  level”  within 
the  Application  intelligent  layer.  As  noted  earlier,  the  Application  intelligent  layer  is 
compo.scd  of  three  view  packages:  Formulator  View,  the  Evaluator  View,  and  the 
Selector  View.  The  Database  intelligent  layer  intcifaccs  would  be  visible  to  these 
subsy.stcm  view  interfaces  which  in  turn  would  be  visible  to  the  subsystems  (all  through 
the  specifications  or  well  defined  interfaces,  of  course).  The  Database  intelligent  layer 
methods  in  Figure  18,  for  example,  would  be  callable  by  the  view  interfaces  tailored 
towards  each  of  the  three  exterior  subsy.stcms.  Figure  19  illustrates  how  the  view-  logic  in 


8.^ 


the  Knowledge  Base  would  call  the  abstract  interface  to  accommodate  requests  made  by 
the  other  subsystems. 


With  the  big  picture  now  complete,  a  word  of  caution  is  in  order.  The  reader  is 
cautioned  at  this  point  that  before  any  attempt  is  made  to  design  applications  for  any 
level  abstract  interface  the  issues  of  type  conversions  and  visibility  of  an  “Abstract 
domain  SQL  base  type”  must  be  understotxl.  Since  writing  the  applications  that  use  these 
SAME  abstract  interface  types  is  outside  of  the  scope  of  this  research,  application 
program  type  conversions  will  not  be  addressed  further.  The  reader  is  referred  to 
(17:69-76)  for  a  detailed  discussion  of  these  issues. 


Figure  19.  Application  Logic  Calls  to  Abstract  Interface 


Summary 

The  goal  of  this  chapter  was  to  emphasize  how  the  STEMdB  could  be  re-designed  to 
be  more  robust,  maintainable,  upgradeable  and  portable.  It  provided  a  top  level  overview 


of  how  an  object  oriented  approach  to  the  STEMdB  design  could  be  accomplished. 

Using  an  object  oriented  approach  to  this  design  helped  to  accomplish  the  goals  of  a  more 
robust  and  maintainable  design.  The  chapter  also  provided  a  method  for  creating  an 
abstract  interface  with  a  database  and  it  presented  a  design  of  a  STEMdB  abstract 
interface  using  that  method.  It  established  that  database  independence  can  be  achieved 
through  abstract  interface  design.  By  achieving  database  independence  the  design  is 
made  more  portable.  The  only  other  issues  that  could  hamper  the  design’s  portability  are 
its  dependence  on  a  commercial  user  interface  and  its  dependence  on  a  commercial 
database’s  dynamic  SQL  capabilities.  The  designers  of  the  STEMdB  should  try  to  isolate 
the  user  interface  and  dynamic  SQL  operations  so  that  the  impacts  of  these  dependencies 
are  minimal  and  localized. 
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V,  Conclusions  and  Recommendations 


Overview 

This  chapter  provides  a  summary  of  the  accomplishments  in  this  research.  It  also 
provides  recommendations  for  re-accomplishing  the  STEMdB  design  and  for  further 
work  in  the  area  of  developing  abstract  interfaces  to  databases  using  Ada. 

Summary  of  Research 

This  research  began  by  surveying  the  literature  for  information  on  what  a  CASE  tool 
was  and  how  to  evaluate  a  CASE  tool  for  a  given  domain.  The  E&V  Guidebook,  IEEE 
working  group  studies  and  the  Lawlis  dissertation  provided  a  .solid  background  in  these 
areas.  The  Lawlis  dissertation  also  provided  an  automated  framework  for  supporting 
decision  support  CASE  tool  selections.  Using  tliese  resources,  the  goal  of  this  research 
was  to  analyze  the  prototype  development  effort,  the  STEMdB,  and  to  provide 
constructive  ways  that  the  prototype  could  be  improved. 

Initially,  the  only  prototype  tool  information  available  was  a  working  prototype 
(along  with  its  source  code)  without  design  documentation.  This  prototype  was 
developed  on  a  Macintosh  environment  called  MacApp,  and  it  was  implemented  in  Think 
Pascal.  Non-availability  of  this  environment  and  unfamiliarity  with  Think  Pascal  made  a 
reverse  engineering  effort  difficult .  Documentation  on  resources  “withed”  from  the 
MacApp  environment  had  to  be  acquired  in  order  to  understand  the  design.  A 
requirements  and  design  document  for  the  next  phase  prototype  solved  documentation 
problems  and  a  thorough  analysis  could  be  made  given  what  this  document  did  and  didn’t 
say  and  given  the  behavior  of  the  initial  prototype.  To  provide  a  basis  for  comparison, 
the  ASSIST  prototype  had  to  be  used  and  understood. 
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The  ASSIST  prototype  was  developed  on  the  HyperCard  environment  using  the 
Hypertalk  language  on  the  Macintosh.  Documentation  in  the  Lawlis  dissertation 
provided  a  lot  of  information  about  the  tools  behavior,  but  it  did  not  provide  enough 
information  on  design.  It  provided  object  diagrams  and  a  thorough  description  ot 
resources  provided  as  well  as  behavior  exhibited,  but  knowledge  about  how  all  the 
objects  interacted  in  the  form  of  a  driver  was  lacking.  To  gain  a  better  understanding  of 
the  design  HyperCard  and  Hypertalk  were  studied.  The  intricate  and  nested  nature  of 
HyperCard  scripts  and  cards  made  it  very  cumbersome  to  accomplish  a  top  level  reverse 
engineering  effort  on  the  ASSIST  prototype.  The  goal  of  this  effon  was  to  see  how  the 
tool  accomplished  its  behavior.  This  knowledge  would  help  in  understanding  the  concept 
of  a  Knowledge  Base  which  was  the  foundation  of  the  ASSIST  design  and  which  later 
proved  to  be  a  good  foundation  for  the  STEMdB  design.  Once  all  of  this  information  was 
understood  it  was  used  to  measure  what  the  STEMdB ’s  limitations  were  given  that  it  was 
not  using  a  Knowledge  Base  approach. 

Once  an  analysis  of  the  STEMdB  was  accomplished,  it  was  discovered  that  a 
significant  improvement  in  tool  portability  could  be  achieved  by  accomplishing  an 
abstract  interface  between  the  tool  and  its  database.  A  third  background  analysis  had  to 
be  accomplished  in  the  form  of  application  programs  working  with  commercial  databases 
through  an  interface  in  order  understand  some  of  the  details  in  this  type  of  approach. 
Oracle  for  the  Macintosh  was  an  implementation  that  was  available,  so  it  was  studied  to 
acquire  this  background.  Information  in  the  form  of  the  SAME  documentation  provided 
domain  knowledge  on  Ada  to  SQL  bindings  that  made  it  possible  to  specify  a  STEMdB 
ab.stract  interlace. 
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Conclusions 

This  research  covered  several  different  domains  to  accomplish  the  goal  of  analyzing 
and  suggesting  improvements  to  the  STEMdB  prototype  effort.  The  necessity  for  a  DSS 
tool  for  CASE  tool  selection  will  continue  as  long  as  CASE  tools  are  used  to  aid  in 
software  development  efforts.  CASE  tool  automatirai  is  essential  to  maintain  control  and 
consistency  over  large  software  projects.  The  STEMdB  provides  a  means  to  sift  through 
the  information  describing  these  CASE  tools  and  to  help  the  decision  maker  make  an 
informed  decision.  The  STEMdB’s  biggest  drawback  is  that  it  is  targeted  towards  being 
operated  only  by  its  developing  organization.  Concentrating  on  only  the  developing 
organization  as  an  end  user  allowed  the  designers  to  make  decisicms  that  restricted  the 
design’s  capabilities.  Hie  tool’s  wide-spread  need  throughout  the  DOD  should  be  taken 
into  account  and  the  tool  should  be  developed  to  support  remote  users.  By  incorporating 
the  design  changes  proposed  in  this  research,  the  STEMdB  can  be  made  available  to  a 
larger  group  of  users,  and  can  be  made  more  robust,  maintainable,  and  portable. 

The  design  can  be  made  mwe  robust  by  encapsulating  knowledge  within  the 
Knowledge  Base.  Any  design  decision  to  alter  the  implementation  of  anything  that  is 
provided  as  a  method  to  the  exterior  three  subsystems  will  affect  only  the  body  of  the 
package  that  defines  that  method  These  bodies  are  encapsulated  within  the  Knowledge 
Base  subsystem,  so  design  changes  like  this  would  only  require  a  re-compilation  of  the 
Knowledge  Base  subsystem  affected  packages  (assuming  Ada  becomes  the  language  of 
choice).  The  ability  to  change  these  implementations  while  not  affecting  the  rest  of  the 
system  makes  this  design  robust. 

Given  that  the  need  for  such  a  DSS  will  persist  as  lo.ig  as  CASE  t(X)ls  remain 
popular,  a  DSS  for  CASE  tool  selection  has  the  potential  to  be  around  for  decades. 
Whenever  software  tools  have  the  potential  to  exist  that  long,  they  should  be  designed  to 
be  as  maintainable  as  possible.  The  existing  design  allows  for  tight  coupling  between  the 
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three  subsystems.  By  designing  tlie  STEMdB  as  an  object  oriented  system  which  isolates 
the  objects  most  likely  tb  change  in  a  Knowledge  Base  subsystem  this  coupling  can  be 
eliminated.  Providing  well-defined  interfaces  in  the  form  of  methods  and  types, 
de-couples  the  design,  which  supports  maintainability. 

By  designing  an  abstract  interface  to  the  database,  the  portability  restrictions 
(resulting  from  a  tight  coupling)  placed  on  a  design  targeted  for  one  specific  SQL 
database  are  lifted.  This  interface  also  allows  the  Ada  applications  to  be  designed  while 
the  database  module  implementations  for  the  abstract  interface  are  being  designed. 

Using  Ada  as  the  implementation  language  .supports  the  concepts  of  abstraction, 
information  hiding,  and  strong  typing.  All  of  these  concepts  are  necessary  to  accomplish 
a  design  built  from  good  software  engineering  principles.  Systems  built  using  good 
software  engineering  principles  have  more  predictable  behavior  and  better 
maintainability. 

Recommendations 

The  following  recommendations  are  made  to  apply  the  results  of  this  research  and  to 
continue  on  with  the  work  of  this  research; 

•  The  developing  organization  should  re-design  the  STEMdB  to  make  it  more  like  a 
DSS.  They  should  use  an  object  oriented  approach  which  isolates  *he  areas  likely  to 
change  in  the  Knowledge  Base  subsystem  part  of  the  new  design. 

•  The  developing  organization  should  incorporate  the  improvements  to  the  present 
design  pre.scntcd  in  Chapter  III  to  make  the  design  more  robust,  maintainable  and 
portable. 

•  The  developing  organization  should  make  the  STEMdB  aucr  j.iblc  to  remote 
users  and  more  portable  by  kxtalizing  the  u.scr  interface  dcpcndcrjics  ttnd  by  designing 
the  STEMdB  in  Ada  using  an  abstract  interface  to  communicate  with  an  SQL  database. 
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*  •  Accomplish  further  research  in  the  area  of  Ada  to  SQL  bindings  by  implementing 

the  abstract  interface  specification  in  this  research.  This  implementation  would  require 
bxperience  in  both  the  SQL  language,  the  SANife  methodology,  and  the  STEMdB 
application. 

•  Use  the  SAME  description  language  to  develop  a  DOD  SAME  compiler  that 
would  automate  the  abstract  interface  process  and  allow  three  expert  domain  engineers 
([The  SQL  implementation  designer,  the  Abstract  interface  designer  and  the  Application 
program  designer)  to  concentrate  on  their  area  of  expertise.  The  description  language, 
SAMEDL,  has  already  been  defined  for  this  approach.  All  that  would  be  required  is  an 
understanding  of  how  to  develop  an  Ada  compiler-like  language. 

Summary 

The  concept  of  the  STEMdB  is  promising.  The  need  for  such  a  system  exists  and 
will  continue  to  exist  as  long  as  CASE  tools  are  required  to  help  manage  the  complicated 
software  development  process.  A  sound,  flexible  design  of  a  STEMdB  system  will  serve 
the  needs  of  the  Air  Force  and  DOD  for  many  years  to  come. 
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Appendix  A.  Example  STSC  Listing  of  Software  Characteristics  and  Qualities 


This  'ippendix  provides  an  example  of  the  Software  Technology  Support  Center’s 
accomplishments  towards  identifying  CASE  tool  software  characteristics  and  quality 
information  in  the  Software  Area  of  Interest  of  Requirements  Analysis  and  Design.  This 
information  comes  directly  from  [18:66-76]. 
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B.l  Functional 

The  foDowing  sections  identify  the  functional  capabilities  of  Upper  CASE  tools.  The 
organizational  hteakout  is  identical  to  the  one  presented  in  Section  22SLI. 

B.1.1  Information  Capture 

The  information  capnire  functionality  area  deals  with  what  types  of  iofonnadon  the 
tool  is  capable  of  handling.  This  informadon  can  be  captured  in  a  number  of  different  ways. 
The  imponanT  idea  is  what  type  of  infonnadon  is  capnued,  not  bow  it  is  captured.  Table  B-1, 
Upper  CASE  Tool  Infonnadon  Types,  lists  die  types  of  infonnadon  that  Upper  CASE  tools 
capture. 


•  System  Funcdon  Descriptions 

•  Dau  Descripdons  of  System  Funcdons  Inieifaces 

•  Data  Descriptions  of  sion  Input/Output  Device  Interacts 

•  System  Logical  Behavior 

•  System  Timing  Behavior 

•  Katdware/Software  Context 

•  Software  Architectural  Stnicniie 

•  Software  Process  Definidofls 

•  Software  Data  Structures 

•  Software  IVocess  Control 

•  Software  Process  Concurrency 

•  Software  Inter-Pocess  Data  Conununicadon 

•  Software  Inter-Process  Synduonizadon 


Table  B-I.  Upper  CASE  Tool  Information  Types 
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B.1.2  Methodology  Support 

Methodology  is  the  process  the  tool  user  follows  to  systematically  develop  correct 
and  complete  work  products.  A  number  of  methodologies  exist  for  requirements  analysis  and 
software  design.  The  important  ones  that  have  been  automated  are  listed  in  Table  B-2,  Upper 
CASE  Methodologies. 


•  Real'TimeSsuctuitd  Development 

•  PAMELA 

•  Sttucnaed  Analysis 

•  ESML 

•  Sttucmred  Design 

•  ADARTS 

•  Hatley/Pirbhai  Extensions 

•  PAlSUy 

•  Ot^-Oriented  Design 

•  VDM 

•  Ada-Based  Ok^-Oriented  Design 

•  Petri  Nets 

•  Object-Oriented  Analysis 

•  Sutecharts 

•  Entity  Relationship  Modelbg 

»  Axiomadc  SpedficaDon 

Table  B-1  Upper  CASE  Methodobgies 


These  methodologies  requite  that  various  work  products  be  created  by  the  user. 
Since  different  methodologies  can  require  the  same  work  products,  the  products  are  listed 
scpantely  in  Tabb  B*3,  U]^  CASE  Tool  Products. 
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•  DiaFIowDugnins 

•  System  Context  Diagrams 

•  BkxkDiagrams 

•  Control  Flow  Diagrams 

•  Entity  Relationship  Diagrams 

•  State  Transition  Tables 

•  Petri  Net  Diagrams 

•  Atchitecttire  Diagrams 

•  Ot^InteractianDiagrams 


Ada  Package  Dqiendency  Diagrams 

Structure  Chars 

FlowCharu 

Screen  and  Repon  Diagrams 
User  Tailored  Diagrams 
Objea  Otienied  Diagrams 
Object  ICetarchy  or  Tree  Diagrams 
Object  Diagrams 


Table  B-3.  Upper  CASE  Tool  Products 


B.1.3  Model  Analytit 

The  model  analysis  functionality  area  capnires  the  techniques  the  tool  uses  to  analyze 
tbempnts.  Ihese  techniques^  be  static  or  dynamic.  They  are  used  to  prove  qualities  a 
the  input  requirements  or  qtecifications  such  as  completeness  or  consistency.  Th^  are 
used  to  simulate  the  inputt  at  an  eariy  suge  in  the  life  cycle.  The  important  technique! 
listedin  Table  B-4,  Upper  CASE  Analysis  Techniques. 


Consistency  Checking 
Completeness  Checking 
Data  Normalization  Atudyu 
Man^oadtine  Interface  Analysis 


Behavior  Analysis 
Scenario-Based  Analysis 
Exhaustive  Model  Analysis 


Table  B-4.  Upper  CASE  Analysis  Techniques 
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B.1.4  Requirements  Tracin{ 

TIk  requttemenis  ndni  fiuictionality  area  captures  die  atiribttiBS  assodaied  with  the 
tndnfofiequiieiiiems  between  software  life  cycle  phases.  Requirements  tradnf  is  imponant 
because  it  facilitates  die  management  (rf  inter  life  cycle  dependencies.  The  imponant  attributes 
are  listed  in  TaUe  B>S,  Requirements  Traang  Attributes. 

•  Extraction  ofRequiremenisftom  System  and  Software  Documentatioa 

•  Inputs  From  Efectronically  Scanned  Hard-Oipy 

•  Multiple  Requirements  Baselines 

•  Tracing  of  System  Requirements  vStrftwareRequiRments 

•  Tracing  of  System  Design  Specifications  to  Software  Requirements 

•  Tiadng  of  Requirements  to  Software  Design 

•  Tiacing  of  Requirements  10  Source  Code 

•  Tracing  of  Requirements  K>  Software  and  System  Test 

» 

Table  B-5.  Requirements  Tracing- Anribuies 

B.1.5  Data  Repository 

The.daa  repository  functionality  area  ogaures  the  anribuies  associated  with  the 
■  database  the  mol  uses.  Most  ttois  use  proprietary  dandwses.  The  daabasemoddpieseniedm 
the  user,  the  user  ianface  m  the  database,  and  the  extent  m  whidi  the  database  can  r^icsent 
...  software  olgects  is  critical  m  the  database's  overall  funcdonaliqr.  Theinqiaftancaitriboiesare 
lisiedin  Table  B^  Upper  CASE  Data  Rqmsiny  Functional  Auriboies. 
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•  Dau  Repository 

•  Contain  Project  Information 

•  Relational  Database  Type 

*  Contain  Requiremenu  Documents 

*  Object  Database  Type 

•  Contain  Design  Spedfrcations 

•  Support  both  Text  and  Graphics 

•  Contain  Source  Code 

•  Query  Capability 

*  Contain  Test  Descriptions  &  Procedures 

*  Access  Control  Capability 

*  Capacity  Artificially  Limited 

•  Concurrent  Access  to  Entities 

•  Support  Interactive  Ctoss-Refetencing 

Table  B>6.  Upper  CASE  Dau  Repository  Functional  Attributes 


B.1.6  Documentation 

The  docutnenuitlon  functionality  area  captures  the  attributes  associated  with  the 
documenution  the  tool  produces.  The  important  attributes  are  listed  in  Table  B>7,  Upper 
CASE  Documentation  Functional  Attributes. 


•  Support  Graphics/Text  Integration  *  Automatic  Generation  of  Documentation 

•  Completely  Compile  a  Document  •  Rapid  Draft  Hard-Copy 

•  On-line  Terx^lates  *  Interface  to  Other  Document  Generators 

•  21 67A  Documentation  Standard  *  Desktop  Publishing  Interface 


Table  B-7,  Upper  CASE  Documentation  Functional  Attributes 


B.1.7  Data  Impoil/Export 

The  data  import/expott  functionality  area  captures  the  attributes  associated  with  bow 
easily  the  tool  can  exchange  dau  with  other  tools  including  other  tools  in  the  tool  vendor's  tool 
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scL  The  imponant  attributes  are  listed  in  Table  B-8,  Upper  CASE  Data  I/O  Functional 
Attributes. 


•  Between  Toolkit  Components 

•  Mth  Other  Tools 

•  CAIS'A  Interface  Standatds/Protocols  Supported 


Table  B-8.  Upper  CASE  Dau  I/O  Functional  Attributes 
B.1.8  Reusability  Support 

The  reusability  funcdonality  area  capnires  the  attributes  associated  with  how  the  tool 
supports  reuse.  The  one  attribute  in  this  area  deals  with  support  for  library  design 
components. 

B.2  Quality 

The  following  sections  define  and  discuss  the  Upper  CASE  implications  of  the  twelve 
quality  attributes  identified  in  the  analysis  phase. 

B.2.1  Efflciency 

Upper  CASE  tool  efficiency  is  the  unount  of  utilization  of  a  resouice  on  a  problem, 
using  the  Upper  CASE  tool  The  three  resources  that  need  to  be  assessed  are  processor  (time 
to  complete  a  task),  memoiy  (the  secondary  storage  requirements  to  conq)lete  a  task),  and 
communication  (VO  and  network  considerations  for  multi-processor  systems  and/or  multiuser 
problems).  For  Upper  CASE  tools,  efficiency  is  not  absolutely  expressed.  Instead,  it  is 
expressed  in  terms  of  accepuble,  barely  acceptable,  or  unaccepuble.  Several  problems 
covtTing  a  range  of  sizes  from  small  to  large  across  each  of  the  resources  need  to  be  assessed. 
When  me  tool  performs  adequately  for  a  specific  problem  with  respect  to  a  particular  resource, 
its  efficiency  is  acceptable  for  that  problem  size  and  that  resource.  Barely  acceptable 
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perfomiance  occurs  when  the  peifomuusce  is  acceptable  but  there  is  no  room  for  performance 
growth. 


Efficiency  as  it  applies  to  the  products  of  Upper  CASE  tools  is  not  important  This  is 
because  the  products  of  these  tools  are  paper  reports.  That  the  tools  may  support  efficiency 
studies  of  their  products  (e.g.,  timing  analysis  of  designs)  is  a  matter  of  funcdonality  and  not 
quality. 


B.2.2  Integrity 

Integrity  deals  with  either  software  security  failures  due  to  unauthorized  access  or  the 
coirupdon  of  the  database.  As  a  policy,  the  tool  users  should  lose  confidence  in  the  integrity  of 
the  database  if  unauthorized  access  is  allowed.  Database  coirupdon  may  be  caused  by  such 
actions  as  legal  but  partial  and/or  inconsistent  operations  and  erroneous  but  allowed  operations. 

The  integrity  of  the  products  of  the  tool  is  a  non-issue.  Accessibility  to  the  products 
is  usually  governed  by  the  operating  system  of  the  developmental  machine  and  never  by  the 
tool  itself.  Once  a  product  has  been  produced  it  is  no  longer  pan  of  the  database  and  can  no 
longer  be  corrupted. 

B.2.3  Reliability 

Reliability  concerns  software  failures.  Reliability  is  normally  measured  by  direct 
testing  and  analysis  of  error  reports.  With  commercial  software,  direct  testing  is  not  feasible 
and  detailed  error  reports  are  not  normally  published.  For  Upper  CASE  tools,  instead  of 
directly  measuring  reliability,  indicators  such  as  manirity,  published  error  reports,  size  of 
executable  code,  and  errors  uncovered  during  testing  will  be  used. 

Since  the  products  of  the  Upper  CASE  tools  are  themselves  intermediate  products  of 
the  entire  software  development  process,  their  reliability  cannot  be  tested. 


.B.2.4  Survivability 

Survivability  deals  with  the  ability  of  the  software  to  perform  even  when  portions  of 
the  system  have  failed.  This  issue  is  not  usually  important  in  the  evaluation  of  Upper  CASE 
toob  because  the  greater  issue  of  system  availability  b  not  critical  in  an  office  environment. 


101 


Upper  CASE  Tool  Characierudes 


However,  if  the  tool  uses  different  hardware  resources  (i.e.,  networked  workstations  with  a 
file  server),  the  issue  of  how  the  tool  handles  hardware  resource  failure  (i.e.,  file  server 
shutdown)  must  be  addressed. 

Survivability  is  not  an  issue  for  the  tool  products  because  they  ate  reports. 


B.2.5  Usability 

Usability  is  the  extent  to  which  resources  required  to  acquire,  install,  learn,  operate, 
prepare  input  for,  and  interpret  output  of  the  tool  or  the  tool  products  are  minimized.  This 
attribute  is  probably  the  most  important  and  cridcal  quality  attribute  that  Upper  CASE  tools  are 
evaluated  for.  This  is  the  quality  attribute  in  which  tool  vendors  differentiate  themselves 
through  such  quality  criteria  as  user  interfaces,  user  documentadon,  and  training. 

The  usability  of  the  products  of  the  tool  is  not  an  important  quality  issue.  The  ability 
to  customize  reports  is  addressed  in  the  documentadon  portion  of  the  functional  capabilities  of 
the  tool 

B.2.6  Correctness 

Correctness  is  the  extent  to  which  software  desi^  and  implementation  conform  to 
specifications  and  standards.  The  correcmess  of  a  tool  is  evaluated  in  other  portions  of  the 
evaluation  framewoik,  namely  the  functional  capability  area.  The  reliability  quality  attribute 
addresses  known  errors. 

The  correcmess  of  the  tool  products  is  important  The  generated  products  should 
conform  to  the  specification  capnired  by  the  tool 

B.2.7  Maintainability 

Maintainability  is  the  ease  of  effort  for  locating  and  fixing  software  failures  within  a 
specified  time  period.  This  attribute  is  not  of  importance  to  the  tool  user,  instead  the  time  and 
ability  for  the  vendor  to  deliver  software  maintenance  is  important.  The  tool  user  is  not 
concerned  with  the  effort  required  to  perform  these  actions.  This  time  is  atldressed  in  the 
vendor  infontudon  portion  of  the  evaluadon  framework  (under  management  concerns). 
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This  aoribute  is  of  imponance  K)  the  the  user  of  the  products  of  die  uxil,  but  not  to  the 
tool  user.  The  tool  products  should  possess  the  quality  attributes  of  maintainability. 

B.2.8  Verifiability  (aka  testability) 

Veiiriability  deals  with  the  design  characteiisdcs  that  facilitate  the  testing  of  the  tool  or 
the  tool's  products.  The  tesdng  of  the  tool  is  important  to  the  developers  of  the  tool  but  not  to 
the  tool  user  (except  that  a  well  tested  tool  will  have  higher  reliability,  etc.). 

The  ability  to  test  the  tool's  products  is  important  in  determining  the  quality  of  the 
tool.  But  for  Upper  CASE  tools,  tesdng  is  best  addressed  as  a  iiincdonal  capability  of  the  tool. 

B.2.9  Expandability  (aka  flexibility) 

Expandability  is  the  ease  in  which  current  funcdons  can  be  enhanced  or  new 
funcdons  added.  Eexibility  is  defined  as  the  ease  in  which  the  software  can  be  changed  to 
meet  other  new  requirements.  Within  the  scope  of  evaluadng  Upper  CASE  tools  and  Upper 
CASE  tool  products,  where  the  viewpoint  is  user  implemented  changes  (not  developer 
implemented  changes),  these  attributes  are  dealt  with  in  the  reusability  quality  attribute. 

B.2.10  Interoperability 

Interoperability  is  the  ability  of  separate  systems  to  exchange  database  objects  and 
their  reladonships  without  conversion.  This  is  an  important  area,  capturing  if,  how  much,  and 
how  well  the  Upper  CASE  tool  implements  data  exchange  standards.  This  area  is  addressed  in 
the  Functional  Capabilities  portion  of  the  evaluation  framework.  It  is  not  an  important  qualiQ^ 
attribute'for  either  Upper  CASE  tools  or  their  products. 

B.2.I1  Reusability 

Reusability  is  the  extent  to  which  a  component  can  be  adapted  for  use  in  another 
application.  Within  the  scope  of  evaluating  Upper  CASE  tools,  reusability  deals  with  how 
easily  the  tool  can  be  used  for  other  projects. 

The  issue  of  reusability  of  the  products  of  the  CASE  tool  is  dealt  with  in  the 
functional  capabilities  portion  of  the  evaluation  framework. 
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B.2.12  Transportability  (aka  Portability) 

Transportability  is  the  ability  of  a  software  item  to  be  installed  in  a  different 
environment  without  change  in  functionality.  Within  the  scope  of  evaluating  Upper  CASE 
tools,  it  deals  with  how  many  platforms  and  operating  systems  the  tool  works  with.  This  area 
is  addressed  in  the  portion  of  the  evaluation  fiamewoik  dealing  with  operational  constraints. 

This  is  a  non-issue  with  Upper  CASE  toot  products  since,  by  their  veiy  nature,  they 
are  repons  not  associated  with  any  particular  environment. 


Appendix  B.  SAME  Package  Listings 


This  appendix  provides  a  listing  of  all  SAME  Ada  Package  specifications  and  bodies 
that  were  used  in  this  research.  The  listings  are  directly  out  of  Graham’s  technical  report 
(CMU/SEI-89-TR-16)  in  [17:143-248]. 
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C.1  Introduction 

This  appendix  contains  the  source  code' of  the  SAME  standard  packages.  This  code  will  be 
available  in  machinenaadabie  form  from  the  Scl  for  a  limited  time.  Please  read  the 
copyright  notice  in  the  next  section.  A  copy  of  this  notice  appears  in  each  file  of  the 
machine-readable  distribution. 

Every  procedure  and  function  declaration  in  these  packages  is  followed  by  a  pragma  IN¬ 
LINE  which  has  been  “commented  out"  The  explanation  for  this  is  as  follows.  Almost  all  of 
the  procedures  and  functions  in  tht'se  packages  are  extremely  small.  Many  consist  of  a 
single  If  or  return  statement  There;ore  they  are  excellent  candidates  for  procedure  iniin’r.^ 
which  will  decrease  their  mntime  cost  by  the  overhead  of  a  procedure  caiL  Experience  in 
using  this  code  with  various  compilers  has  shown  that  this  degree  of  inlining  tends  to  uncov¬ 
er  compiler  errors  and  produce  inexplicable  timings.  The  safest  approach,  that  of  not  using 
inlining  at  alt,  has  be  chosen  for  the  cods  as  distributed.  The  installs!  is  urged  to  experiment 
with  the  inlining  of  this  code.  Some  experiments  have  shown  a  tenfold  speedup  due  to  inlin- 
ing  (whereas  other  experiments,  on  other  compilers  and  machine  architectures,  showed 
marginal  slowdown  due  to  inlining).  Recall  that  inlining  will  usually  make  the  resulting  object 
module  larger. 


C.4  SQL_Standard  Specification 

paekaga  2!gl_S«aadar4  la 

packaga  Cbacacsar_Sae  caaaaaa  csrp; 
aubc^pa  Charaeear^Tjpa  ia  C>axaetas'_S'ae<ea«;. 
typ»  0»ag  ia  axray  (poaibi-ra  raaga  O) 
of  Charaecaajggpa; 
typa  Saailiat  ia'^saaga  ba.  .ta; 
eypa  Zm  ia  saaga  bi..bi; 
bypa  Saai  ia  digi&a  dr; 
typa  9ottbla_?raeiaioa  ia  digits  <^4; 

^yp*  PaciaaT  ia  %a  ba  dacasatia'vd; 
typa  Sgioodajtypa  ia  raaga  bae..tae; 
aubcypa  Sgl_Xrsor  ia  8gleada_Typa 
raaga  Sqt^oda^Sypa' 72LS7  ..  -1; 

•nibaypa  Xoc^faaad  ia  SglsodaJIypa 
raiu/a  tOO..iaO; 
aabaypa  ZadieaaarJSypa  ia  r; 

cap  ia  aa  iaplaaaaCar-dadiaad  paekaga  aad  eae  ia  aa 
iapiaaMatox'dadiaad  characr  ir  typa.  ba,  ta,  bi,  ti,  dr,  dd,  bae, 
aad  tae  ara  iaalaaaacar  da*!;  aad  iatagxal  aaluaa.  t  ia  iat  or 
aauLiliac  eorraaeoadiag  to  *,  •  iaplaaaator-daliaad  <axaat 
auaaric  typa>  a£  iadicacor  paraaacara. 

aad  agl^ataadard; 


C.5  SQL_Communications_Pkg  Specification 

aitb  SCLjSiar^Skg;  aaa  SQijSbarJPkg; 
witb  SQti^Staadard;  aaa  SQL_Staadaxd; 
paekaga  SQi^r 'i—in I catioaa~gkg  ia 

Tbia  ia  aa  axaapla  o<  tba  paekaga,  proridiag  atnlaal  fiiaetieaaiity. 
Tbia  paekaga  aay  ba  tailerad  ta  tba  aaada  of  a  giaaa  pXattfera. 

IJ 

SQL^OatabaaaJteror  :  awaptioa;  | 

I 

■q&coM  <  sQscsoijtsn; 

~  yarawatarlaaa  foactioa  rotaraiag  aa  orroar  taaiiga  o<  typa 
—  iQLjCbarJfatJkai. 

~  Tba  aonar  ■aaoTga  ia  tba  daaeriptiTa  atxiag  aaaoelarod  aitk 
~  tba  soot  Taoant  databaaa  arxor.  Zt  ia  prodaoad  by  a 
~  OMt  ■paeitle  Taaetioa. 

Toastiaa  tflL Jat  abaaa_lx«er_llaaaaga  ratara  SQL_Cbar_Bet^iall; 


aad  SQLje 


C.6  SQL_Communication$_Pkg  Body 

~  dOb^<*r— ili>i  iial  ii^ajkg  ia  a  "pi atfnra-apani  f1  n*  partgqa 
>-  wttbia  tba  Mata  “ 

~  tbia  parttcalar  aaraioa  oT  tba  paekaga  aaa  daaalepad  for 
~  a  piatfoae  oooaiatiag  of  tba  Tardir  (7araiaa  S.41)  Ida  aoapilar 
—  aad  nwaif  (Varaida  9.0)  raaaiag  oo  a  Vox  Statioa 
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axtb  syctsaai.*  om  aya««a; 

wttix  SQZ>_Syss««;  m«  SC^^Sysea^; 

n£it  id9xaa_e_«appars;  oa*  ia^raa^s^auppars; 

~  ia9Saa__e_aBpporS  eoaealaa  £aae&iaaa  AddJIitLl  asd  S1:s%PjlalX 
~  whicit  asa  aaad  to  eaovost  batvoca  *e'  fnraac  atr^  •ujm  aad 
~  Ada  'oxaat  atrlaya.  Z%  la  aoc  iaeladad  la  tha  SAMS  ataadasd  paalea^aa. 
paeka^o  body  i  am  i  i-j  iii  r_— ~j  la 

Ssaetioa  SCIiJ3atabaaa_Z5r9r_Maaaa9a  ratusa  SC»_Cbar_So«_!fiill  la 

Naaaa9a_3addar  :  SCXij!^aC_Sot_l(i:.lZ  (1.  .MAXZaSLZS)  ; 

Im  :  iasa^ar  :■  MUOSUtUS; 

pcoeadusa  gataxraaf  (Maaaa^a  :  la  Addsaas; 

Irta^eb  :  la  Addraaa)  ; 

pra^sM  latac^aea  (C,  (tiaasaa?,  '^a^IacsMf'*} ; 
bagla 

gatassaa^  (Maaaa9a_3uiZa;' Addaaaa,  Laa' Addraaa )  ; 

~  tba  aaataptioa  bar#  la  tbae  ao  arror  aiJLl  ocesr  ahaa 
—  raeriaaiaf  tba  arrac  aaaaa^a  dreai  tha  dacabaaa 

aaeasa  acsip__attll(2teaaa9a_3Bddac) ; 

aad  SQI^J3a«aaaaa_3rsag_Maaaa^; 


aad  SQSi^Coa3Bsi.satl.oaaJ?ic9; 


C.7  SQL^Exceptlops  Specification 

pmakagm  SCL^wnaptittna 

j;  I 

MsU^alMjteroc  d  aaoaptioa; 

^  I 


C.8  SQL_BooIean_Pkg  Specification 

pacifja  Sgt  loafoin  tkg 
ia  "  ■" 

tjpm  Baalaoa^aAtbJhilraoaa  la  (ISUS,  nOOW,  XSSB) ; 

—  —  Xhcaa  TaXwad  tagia  npaaotiona  ~ 

thgaa  Tal  X  tbraa  aal  ■>  tteaa  -omI  ~ 

Soaotlaa  "aa«*  (ZaSk  :  laal a oajojtbJbJroiaai ) 
sataaaa  loalaaiiJrttbJBuiniiii? 

—  |ira9aa  SStTW  ("aa*"); 

Saaakioa  "aad**  (ZaSk,  light  x  laaXaaajaikhJUaaan) 
aataa  Boalaaa^vithJOhJMw; 

~  psagaa  ZSIJIS  ("aad*};  ~ 

ftsaetioa  "a«"  (ZaCt,  light  ;  loalaaa_oithJfafcaqwa) 
xataca  Boeiaaa  with  tinimnan; 
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—  . . . . .  .'tfll  . . I  I  I  t  ,  t-t  M  ■■♦■■fr-H- 

—  7^«  fallowiaf  eopyri,9hs  asu'C  bm  iaeludad  la  ehl«  aaftvaza  and 

—  all  sadtvara  oellizia?  ah; a  aodtwara. 


— >  Capyss^ha  (C)  1988  by  a^*  Casaagxa  Halloa  OaaTassaay,  Paaaabnrgh,  ?A. 

—  Zhm  Sodawasa  Zagaaaazaag  Zaaaaaaea  (S2X)  la  a  iadazally  fandad 

"  saaaaraa  aad  daTalopaaaa  eaaeaz  aaaabllahad  aad  opacaead  by  Caraagla 

—  Halloa  Oaavaasaay  (CHD}  .  Spoaaezad  by  aba  O.S.  Dapastaaaa  oi  Daiaaaa 
~  oadas  seaeraea  719828-85-0-0003,  tba  S21  la  auspozaad  by  aba 

—  sas7leaa  aad  da£anaa  a^aaelaa,  wiab  tba  tJ.S.  Hr  Forca  an  aba 

—  axaeaaiTa  eoaaraeaia?  agaaa. 

—  Pazslaalaa  to  aaa,  copy,  a»dl5y,  or  diaarlbuaa  abia  ae5a»ara  aad  ita 
~  deeusaaaaaloa  for  any  purpoaa  aad  aiaboua  faa 

—  la  baraby  ^raaaad,  provadad 

—  abaa  aba  abvrm  eepyra^ba  aoaica  appaar  la  all  eopiaa  aad  abaa  boab 

—  abaa  eapyragba  aoaaea  aad  abla  pazauaaioa  aoaica  appaar  la  aujpocalag 

—  deeaaaeaaaloa .  Tarabor,  aba  aaaaa  Saftwara  Za^aaaarlag  Xaaaaauaa  or 

—  Cassava  Halloa  OaaTorsaay  aay  aoe  ba  uaad  la  adoaraaala^  or  publlcray 

—  paraaaHag  to  dlacrabtialoa  of  aba  aofawaro  waaboua  apaclflc,  wraaaan 

—  prior  paradaalon.  CMC  SMjcaa  ao  claiaa  or  rapraaaaaaaiooo 

—  abotza  aba  aalaablllay  of 

—  abaa  aaftwara  far  any  pcrpoaa.  7bl*  aofawara  la  praridad  *aa  la" 

--  aad  ao  warsaaay,  aspraaa  or  la^llad,  la  aada  by  aba  S2I  or  CHS, 

—  aa  ao  aba  aeearaey 

—  and  fssealonmg  of  aba  prograa  aad  ralatad  program  uearlal,  nor 
~  aball  aba  faea  of  dlaarlbualoa  conaaiaaaa  any  aueb  varranay.  Ho 

—  soopocaiblllay  la  aaaasad  by  tba  5ZZ  or  CHC  an  eonnaealoo  horawaab. 


C.3  SQL_System  Specification 

~  SQLjSyvtaM  is  a  "platfoxa-opoclfie”  paokago 
—  within  abo  SbMK 

packago  SQXi_^Syata«  1« 

~  MMCCajCZM  la  tba  laagtb  of  tho  loogoot  ebaxaetar  atrlag 

—  whlob  abo  OMS  will  otoxa. 

—  Xt  aorroo  a«  tba  oppar  beoad  oo  tOlijSbarJfkg 

—  oubtypoa  JQ&jCbax^Laogtb  aad  80I.J0bpaddod_Laogtb« 

—  SQLjCbar  Laagtb  la  a  aabtypo  of  lattral  witb  a  lewoc  bound 
~  of  1.  ” 

SQLJBapaddod  Laagtb  la  a  oobtypa  of  Xattral  wltb  a  looor 

—  booad  of  oT 


MUCCSKUEa  :  oaoataat  latagor  :■  atr_laagtb;  xaplaoo 

—  MbXZSUCZa  la  tba  ooxijnao  laagtb  of  tba  arxoc  aoaaaga 
—  otxlag  zatosaad  froo  ObllS  opaeifie  arzor  Moaaga  rootlaa 

MbXZIQlXJtS  :  ooootaat  iotagoc  :■  oogjlaagtb;  —  aMplaea 

aed  SQL_SyatM; 


109 


“  Jor  tha  SCZ_^Issurr»l  cyp* 

£unesiaa  "+"  (Rigat  :  SCl_Iac*rvai.)  r»««=  S5-_I“t«rTai; 

^aaeuoa  (iligac  :  SC-_:ac«r^I)  zacuaa  SCl_lnt«rTai; 
iuocsioa  "aba’dligis  :  SCI  lacaznd)  raca=  SCIi_Ia«*rT*i; 

—  pragu  SC^  ("«b»') ;  ” 

~  fal^owiag  fsaeslona  ia^lsMna  r**~»a  ralaad 

—  aeasiaaeic 

~~  iJl  ^***’^r  iapua  aa  may  o£  shaa*  Saaeaiaaa  ia  anil 
~~  tha  fnacnlaa  raeaasa  aha  anil  ▼alua;  oe^iarviaa 
~~  pasfasa  tiia  ladleanad  oparaclea 

titmmm  Ssaesiaaa  sai,a»  ao  azcapclena 
^naenlaa  *■*••  (lafz,  %zg!:a  :  SQl_IaaarTal)  raensa  SQI,_tatarT»l; 
iuaesioa  ?lna(laSZ  ;  SCi^laear^ai;  Righa  :  SQLJData)  rataaa  SClJSaca; 
Suaesloa  ?laa(La£a  :  SC:>2^as«;  Kighs  :  SCl^lanaml)  raenaa  SCl~Dana; 

—  pragma  SC^SZ  ("f’);  “  -  .  - 

fnaesaea  "-•*  Saghs  :  SQI._IacarTai)  rannaa  SQIi_Iaearral; 

^aaeslaa  MiauaC^t,  Illghs  :  SCl_9ana)  zaenaa  SQL^Iaearral; 
fsaeaiaa  ltiaua(Lait  ;  SCl_Daca;  Righc  :  SCl>_taearTal)  racna  SQLJCaea; 

—  pragma  21132  ” 

Snacsian  (lait  :  SQl_2»aarTal;  Xighr  :  iasagar)  satata  SGl_:a«arTai; 

—  pragma  2»12a  {"**)  ~ 

^raealaa  "/"(lait  :  SQl_2iearTal;  Righr  t  iaragaz)  ratnsa  SCl^Iatatrai; 

—  pragma  2Hrt2  ("/*);“  "" 

—  laglaal  Cpasaelana  — 

~  sypa  X  rypa  *>  3oolaaa_«iSi:_'cakao«s  — 

—  nhaaa  feacaiana  isiplamaae  ahraa  raluad  lagie 

If  alsiMr  iapua  ia  tha  anil  ralua,  tiha  faacaiaoa 
»  racnsa  tixa  trss^  Talaa  tntIQIOMH;  ocliarviaa  thay 
~  parfasm  rtia  iadieaaad  eec:puN,Mea, 

—  tjutaa  fsaesioaa  raiaa  ae  axeapcraaa 

faaesiem  ZguaJ^  (l>aft,  Itigiks  :  sd^Oaea)  xaesza  loolaaa^nxt&^aakaoim; 
fnaeniam  «  (laft,  itighs  :  SQl_lBCar7al)  raensa  Boalaaa^was&JOakaowB 

— '  pragma  2fX32  (Zgnala); 
fsaenioa  SoeJBguala  (laft,  Right  :  Sd^Dar*) 

BoelaaB_«ith^tTalaiema; 

fanction  XotJ^nala  (laft.  Right  :  Sdjlararral} 

amtuaa  Roolaan^withJPnknnaa; 

—  pragma  Oot_lgBala); 

fsaetiam  ”<*  (laft.  Right  :  SQl_Oata)  ratara  loolaaajaithJOafaoam; 
faactiam  ”<**  (laft,  Right  :  SQl_ZatarTal)  rmtarm  Boelaaa_*lth_Oaksoaa; 

faiMti^ ”>'  (laft.  Right  :  Sgi.Data)  ratsrm  Reolaamjid.thJDBteoBa;  ' 
foaetioa  *>*  (laft.  Right  :  SQl'zatarral)  ratara  loolaaaJmttthJBalMoam; 

faaecioa  "«b<*  (laft.  Right  :  SQl_D«ra)  lacvtut  R<wilaanjri,thJBn)moan; 
faaotiaa  daft,  :  Sd^latarral)  xatura  Xeolaaa^jaithJBataeoa; 

fametiom  *>*'*  (laft,  ■’tg***  :  Sd.Otra)  xatma  RoolaaajaithJahaoan;  ' 
foaetiom  "tm”  (laft.  Right  :  ratara  RaaTaaa^i^thJBulnini ; 

—  tjpa  a>  bantaan  — 

foaetiom  ZaJhtlKValao  :  Sd.Data)  ratara  Bealaaa; 
foaetioa  Za'«oll(Valaa  ;  Sd**XataraBll  ratora  Raalaaa; 

—  pra^  dasa  (lajhdl)  ;  “ 

foaetioa  •et_«oU  (Valoa  :  Sdjiata)  ratora  Beolaoa; 
foaetioa  RatJtalKValua  :  SQl^Xatarval)  ratara  Roolaoa; 

—  pra^  ndTRR  («at_llall) ;  " 

foaetioa  Za_TaarJMaath(Valna  :  Sd^Zetarral)  ratora  Boelaaa; 

pragaa  2I12»2  (:o_Taar_Naeth) ; 
faaetxoa  Za_pay  7ijao(Valua  ;  Sd^Intazral)  ratora  Boolaaa; 


no 


gs«eslon«l 


t.'rp*  SCi  3«e«tia«  ?i«li  t*  {y***'  <i»y; 

“  “  hous«  •xJJUt*/  »»coad,  ,s»ctAoo) ; 

tvp*  set  3«t«  Slo«  SQtjaiArJIoeJIiill; 

W9*  SCi"3«*T3r=«  :  SCtJ)%e*6ia*jri«i<i; 

~o  :  seiJ5«c*eia*_.i’i»i-->' 

{•-aesioaai  :  orBCiaioo)  i»  lA3i.s»«l  pri.T«c«; 

tr/o*  SCI  lasM^KTzo-  *  :  SCt_D«.tia*_?i*l-i: 

**  "  i«*dia9  : 

»o  ;  SCtJ)*c«eia«_?i«l«>‘ 

:  pc»e±sxoa)  J-*  priT»t«, 

2uae£i.aa  Hail  SQiJ5*t«  r«eu=»  SCtJJ***'" 

—  pra^a*  2Ii5b  “suil^SCt  J>*e«)  •' 

^oaestaa  Hull  SCt  Isaarrai  raeusa  SQt_Ia5«r»»t; 

—  psa^sa  2{LSIZ  Ti«uiljSCX._3sc«C7ai)  ; 

—  ti^a.  Juattiona  zacura  aixa  not-auli  poraisa  oj 

*»«i.aa  Hizhaua  Hull  aaa«(V*lu.  :  S«t_Oata)  raeuza  . 

iua«l.aa  Hishaua JJuil.Saaa  r^aiua  :  SQt.Iacac^)  zacuca  SQI._OaCa^SotJIU 

—  pza^aa  ; 

—  aiia  Saacciaa  z.auza.  aa  ob3-«  <>« 

—  coafaxziac  tta  it  £s<»  si-  obj»e^  o£  typa  SQt_tatarTa- 

iaaetioa  ta  O^sisa  (Valua  :  SCi_Iat.«ai)  raeura  duraezaa; 

—  pza^aa  ^tUB  (Tajiurasioa)  ; 

—  tii.  iuactioa  zatuzaa  aa  abjact  aS  tb.  cal^daz.t^  t-^,  aitaz 
~  eoaaacziaf  ta  it  Sss»  si-  iap**  obj*cz  o£  sy?-  S0l._.0ata 

£UttC««Oa  ?0  ?«aSM  {V*it4#  •  S*CUKl 

•«  pr»9aa  ^ixzSZ  (?aJ7l3«) ; 

~  ti-a-  Procter.,  p-s.-  <»S  typ. 

~  ti.  Ltatia.  «id  iatar^  St-W  tI—  to  tb. 

•—  set  Data  aad  SQL  latazrai,  uaiap  diaertataaaea  that  I  .j„  _ _ 

—  th.  «M«  ia  th.  abatzace  da-a^  ftr  tha  abjact  -baa  it 

—  daelazad.  a  conatzmiAtjarsw  wtU  ba  rai^. 

pzocaduza  Sana  aBdJUai9»_»aa.(t.<ts  *»  • 

”  *“  p^  ;  fQt^Oata^aftJbtll) » 

p«oe«taza  ta»a_aadJUai9#_3— .(!.»*  *»  •«* 

*”  tlpbt  ;SQtJpa»aJtot Jtall) ; 

->  tM.TM  (tazaajwd.tMi9a); 


—  tbla  teetloa  aceapca  iapae  mt  tjp.  ***?^*f*l*^^*C « — 
~  saezm  aa  objact  at  *jpm  SQLJtMCfmX  abaa.  oat-«iU 

—  haa  tba  aacsact  SQt  -iatazrai*.  aaiaa 

~  (faCH  ->  day,  UMX3K  a>  2,  tO  a>  teaet^, 

taMCloB  ta  SQL  latazaal  (▼aioa  ;  dozatioa)  zaw=»  SQWatazaaX. 

~  jn-pia  ^--rn  (TojtQt^Xaaazval) ; 


-  «bla  SaaotlM  aacapta  iapat  a£  typa  awada^t^,  .«• 

~  zacsaa  aa  abjact  a£  ^rP*  SQt^Oata  «*aaa  aaC-aaU  paztioa 

—  baa  tha  cocract  SQt  -datatiaa'  yaloa  apaeiflcttioa  fezaat 

Ta  SQtJ)ata  (Valsa  s  Uaa)  ratata  SQtJData; 

»-  r~— -  m-f”  (To_SQtJ}aKa)  ; 


~  tha  Bxaeadaza  aaaipaa  SipbS  *•  ta^S  __  _ 

ocaeadazs  jUaiai(ta£t  :  la  act  SQtJSata;  hlQha  :  SQlJ>tta); 
^^adaza  Aatl^{la£t  :  la  act  SQtJCatarrmi;  RiQbt  s  SQt_Iatar»»l)  ; 

—  pza^ta  latsa  (Aaai^);  ■ 

»_  »>.-  SoUoatap  thzaa  Suacsiaaa  iipplaaaat  aaazy 


"aba' 


raCttsa 

•ed  i£: 
•ad  7alu*; 


( SOL_t  mi—  ratioa_J»oC_SttLl '  VaJlaa  ( 
?a_Striaf< Value) ) )  ; 


•ad  SQ:iJCatiBeracMa_?k9; 


C.28  SQL_Datafaas8_Error_Pkg  Specification 

package  SQZiJDaeaaaaa_ZS70c_?kg  ia 

~  Sm  £eUewug  praeedcc*  auaC  ba  pnaaas  ia  aeacy  eacsioa  e£ 

--  SC^JDaeabaa*_Zrs9S'_?]cg.  Xt'  a  purpeaa  ia  £a  pac^oca  acaadard 
—  psacaaaiag  of  uaaasaccad  aaccapciooai  coadisioaa.  li  ahould  aec 
-*'*  a***  Tf  asioc  raecrear. 

psaeadcra  ?sacaaa_OacabaaaJbsor; 

•ad  SC— _Jtatabaae_2as3aJ?)cg; 


C.29  SQL_Database_Error_Pkg  Body 

wlab  ?exs_^IO,  SCSMT-— unii;  ■*  innaJHcg,  SQLJtoa«_T2paa_fk9; 

«••  Taxs_XO,  SCL_,CaaaBaieaciaaa_Skg,  S6X.Jtoaa_‘:;fpaa_?kg; 
package  bedp  SCL_Oacabaaa_ZsxosJP)cg  ia 

pracadnra  Vsoeaaa_DacabaaaJC=rec  ia 

begia 

—  fxcaedara  fsaceaajat.abaaejfcgeg  ia  eaUad  ia  aaapaaaa 

IMI  mi  (MI  •CXMt  • 

Bm  pBoeadac*  aay  be  andifiad  pec  . 

~  the  aeada  aS  tba  lhatraet  Xacerfaaa  daealapac 

~  Sbia  ia  a  aiaiaaT  iaplaMaCaUaa. 

—  Set  a  daBcripti-aa  eccec  aaaaaga  Cena  tba  IflMi 
— .  (tbeoagb  tbe  parkage  Sflb  rnaanal  itaf  <  nnajkg) 

—  aad  diaplagr  ib  oa  aCaada^  eaepab. 

paC_Uaa  (SbjMxiag(Sa&JChacJtofeJtall(aaPE._Oa«abaae_SccarJtaaaage))) 


C.30  SQL_Date_Pkg  Specification 

attb  Sgt^Staadaxd; 

Bribb  CaXaadax;  aae  Calendar; 

«lbb  ipt  Jaa  1  a  an  Jbg;  aae  sqtJleelaaaJMtg; 
altb  SQL  Cbac  tkg;  aae  SQL  Oac  fkg; 
paakagn  SOL  Oace  Ikg  ' 

la  ”  ” 

bppe  preriaioa  ia  range  0..X0; 
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Soolaaa  :<■  ts^ft 

V4lu« :  SC-_ZauMrasi.aa^lioc_MuXX; 
•nd  racard; 


•ad  SSI>_ZataaasK::oa^9k9; 


C.27  SQL_Enumeration_Pkg  Body 

Widb  SSXi_Zxeap'%iaaa; 

paeka?*  iMdy  SSl_SaBait:a^aa_?k7 


iiull_Vala«_JZarar  :  «xs«p«doa  - - -  SQL_Zxonelaaa.MuH_jralu*_Ilsri 

doas^ioa  Htill^SS«_Z8aa«rasdaa  saesra  SQLJCauaaraadaa  la 
Htlll_Jlaldaa  :  SCl_Za«aMrasloa: 
b«?la  ~ 

s««tt=a  Hiill_laldas; 

•ad  Httll_SSZ_2su>a=aalaa; 

daaealaa  Wl%dan_HtiH (Valaa  :  la  SCL_ZaaM:aslaa) 
saaasa  SCl_^Za:aasaalaaJioc  Nall  la~ 
ba?i3  “  “ 

Id  Valaa.da^Holl  akaa 

saia«  S«IllJfaia«Jtssa=; 

•laa  “  ** 

s*%ssa  Vala«.7ala«; 

•ad  Id; 

•ad  Kladeea  Mull; 


daaeulaa  HladJHuU  (Valu*  :  la  SgS._Zaaa«saalaa_Me'S_Ilull) 
saussa  SQSiJEaaaasaalaa  la 
b«9ia  ' 

sacuaa  (lajiull  «>  dala«, 

••  7alua  «>  7ala«) ; 

•ad  KltkJlTiU; 

pco««d«r«  Aaalpa  (Z«dt  i  la  aaft  SQLJBaaaasaUlea; 

Ilpdu  ;  la  SQEi  Inwanttlaa)  la 
bagia  ~ 

;■  Xl^; 

•ad  Aaalga; 

dtaeaiea  Z<{aaXa  (Ladd,  Light  :  SCSJbaMxatlaa) 
ssuasa  aoolmta  With  Qakaora  la" 
iMigla  **  “  , 

Id  iHidt.Za^Ilall  or  ala*  Sight. Za^XoU  thaa 
ratura  Oakaoita; 

•laid  Ladt.7alaa  ■  Sight  .Yalta  than 


ftsra  Falaa; 

•ad  Id; 

•ad  Sqaala; 

doacuioo  Sotjtgoala  (Ladt,  Sl^  :  SgLJtaraaaratioo) 
ratara  Baolaaa  Wish  Ookaoan  la  ~ 
bagla  ”  ** 

id  Ladt.IaJJuU  os  alaa  Sight. XaJJuil  than 
ratssa  Onfcaowa; 
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^  t^aa  ftaesioaa  ruaa  ao  azeapc^ana 
Sax^c^^ea  (:.aZ%.  SLifiis  :  SCIi_2auaasasi.on) 

saeusa  aeolaaa_vaa&_aaicaown; 

•oatfsiaa  Hos^JS^nala  (I>aia,  U^hc  :  SC!>_Zs'>=MnuoB) 

••casa  Saalaaa^w&ah^OalBioaa; 

~  ??a9aa  SC3Z  (Sot_Z^xiaia)  ; 

Zaaesiaa  *<“  ar?aa  :  SOt^Zaiaaasacion)  raeasa  aoala*a_withJIakaowB; 

iaaesioa  *>■*  ai.^a  :  SCxT^Zaiaiasasiaa)  racara  3oalaaa_«athJIakaowa; 

^aaesaoa  :  Sci^_Zaaaa:aaiea)  raeasa  Boelaaa_via^^Onjeao«n 

'faacai.as  *>a*  (Zia^,  :  SClJZaaaasasaaa)  xacasa  aoolaaa__wlt:&_^Oa:cae«n 

—  t?pa  a>  boolaaa  — 

faaesiea  Za^Hall  (Valaa  :  SCL^Zaaaacaaioa)  racara  Baolaaa; 

—  psa^  iSlsa  (ZaJIcll)  ; 

^aaeci^as  Hoe  Ha.;^  fvZlaa  :  SGt_Zaaawraei.ea)  racara  aeolaaa; 

—  pra«M  a&ba  (Sacjlail); 

^aaecles  *«"  {I<aiC,  aiifbc  :  SgZ^Zaaaaraci.ea)  racara  aaolaar; 

—  pra^sa  ZSZZSZ  {*■*)  ; 

iaaeciea  'K**  fZ<a£t,  :  SQL_2auaaraciaa)  racara  Boelaas; 

—  pra^aa  HCZaZ  (*<")  ;  ~ 

^aaecrea  ‘'>‘*  :  SCt_Zaaaaracroa)  racara  3oolaaa; 

—  psa«SLa  25=^32  (*>*); 

daaecraa  *<■"  Jlifisa  :  SCZ>  Zaaaaracaoa)  racara  Beolaas; 

—  pra^  2T22IZ  ("<■-); 

Aaeciaa  '*>0''  (tlraft.  Bi^hc  :  SfiLJZacaaracraa)  racara  aoelaaa; 

—  pra^  2C2a  (*>-'); 


%^a  ialZawiaf  aia  Zasecioaa  siarc  Cba 

—  'Srai,  'Saec.  '2aKa,  'Pea,  '7al,  aai  'Vaiaa 

■*>  aecrrbaaaa  e£  eba  SSl^ZaaeMracioa^Hes^Halb  sypa/  paasa^ 

~  ia,  Zer  Cba  aaaoeiaaad  S^t^Zamaraeioa  (aaJLl)  '^a 
*—  tbay  all  sajam  tba  Hell^7alM_Zrror  axsapcroa  iZ  a  aall 
~  ralaa  la  paaaod  la 

~  frad  ralaoo  cba  Coa«aralae_Zrsor  axeapclaa  IZ  tha  Talaa 
*"  paaaod  la  la  a^aal  to  SClJE8SBaaaaeisaJSac_attll' laac 

—  Saco  xalaoa  tba  Coaacsalac_Zsrar  ttccapeloa  iZ  tbo  valao 

paaaad  la  la  aqaal  to  ZqLJtnuaaritlae_Hoe_Hall*  rirat 
~  Tal  ralaoa  tbo  Caaacaaiat  Zaror  axeapiZ-ea  IZ  tba  ralao  paaaad 

la  la  aot  la  tbo  saa^a  F'aasCH'TSSZ)  ,.9'70»(?’tASr:)  Zor  tjpa  Y 
▼alca  ralaoa  tha  CoaacsalaCJtrrar  aaeoprcloo  IZ  tbo  aarpiaaoa  oZ 
oharaocoss  paaaod  la  doaa  aoe  bara  tbo  mjatax  oZ  an  amTant'nn 
~  litoral  Zox  tbo  inatantiitad  aocMratloa  tjpo 
Zaaetloo  Yrad  (Valaa  :  la  ZQL^lBaaratlao)  racara  SQZ>_ZanMratloe; 
prayea  BnJB  (Yrad); 

Zaaotlea  Saea  (Valoo  :  la  SQLJBaaaarBtloo)  taCBaa  SQLJZacHocatloe; 

~  pra^aa  SKaH  (Saee) ; 


Zoaecloa  Yoa  (Talaa  :  la  SQl^ZBaaaratlao)  racaa  Zatagor; 
pxa9M  STEJaat  (Yoa); 

Zaaotioa  Zaago  (Talao  :  la  SQL  Zwaaaratloo)  racara  SQL  Cbas; 
Zaaetloo  1.09.  (Talaa  :  la  SCL_Zaaoaxatlaa._Hoc_Hall) 
rataaa  SQL jSuur^Vot^Hall; 

—  pra^aa  ZXLlSt  (Zaofa)  ; 

Zaaecloa  Tal  (Talaa  :  la  Zato^ar)  racara  SQL_Tnne  ■  L-acloa; 

~  pra^aa  ZHLSB  (Tal)  ; 

Zaaecloa  Talae  (Talao  :  la  SQL_j3iar)  racara  SQL_Zaaaoratloa; 
Zaaetloo  Talao  (Talao  :  la  SQLjCbar_lleC_Yall) 
xaCasa  SQL  ZaasMzaCloo_HeC_Hall; 

—  pragma  THL7TT7;  (Talaa) ; 


pdTaCa 

t^rP*  SCI  Zauaoraclen  1«  raeerd 
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—  psMga*  ("<■“»; 

tancrzxea  "><■"  iUghc  ;  SGL_CSi»r)  rscura  aealMs^wiUiJOakaown 

~  pra^a  SdiiyS  (">«"); 

—  Vjpt  ■>  booiaaa  — 

iaacbioo  Ia_Huil  f/alaa  :  SCl_Cbar)  tatusa  aooiaaa; 
psa^M  SILI^nt  (ZaJloU.) ; 

iuacsioa  (Valaa  :  Sfii_Ciar)  ratusa  aoolaaa; 

pra^u  ZtLSnt  (HoejKoLl)  : 

—  Sbaaa  fuaesiaaa  ai  elaaa  byp«  ■>  beolaaa 

—  aquaca  ONRiaWH  r:^M2.*lbae  ia,  tbay  racasa  THOZ 

4  oaJLy  afaaa  aba  ^aaea.aa  racaraa  TAOZ.  OUKbCWN  mad  FAXmSZ 
aza  aappad  ta  rSXiSZ. 

Zaaeadaa  (Z*£^,  Zi^he  :  SQLj::hMr)  zatasa  Zaolaaa; 

—  pza^aa  StLIMZ  (”■“}; 

iaacaiaa  "<*  (LaSb,  Zighe  :  SQt^Cbar)  tatara  Zoolaaa: 

—  pza^M  SCiIitZ  ("<"); 

2aaeaa.aa  *>'•  (Lait,  Zigbc  :  SQtjSiMS)  tatara  Zoolaas; 

~  pzagsa  STLStZ  ('•>"); 

faactioa  ■•<*••  (tadb,  Zigbc  :  Sflt^Cbaz)  tatara  Zoolaaa; 

—  pzagaa  20.2^  (•'<*“); 

iaacciaa  *>■'•  (laSt,  Zigbc  :  Sfltj:bac)  tacata  Zoolaaa; 

--  pza^aa  2:t2.2inC  {">«“)  A 


cba  pazpoaa  oi  tba  iallowiag  ganarte  la  Co  gaaazata 
coaTazsioa  iaaeciaaa  boeoaao  a  typa  dazt7od  £som 
~  SCr.j:baz^Mot_Haii,  ahicb  aza  afiacciTaly  Ada 

scziaga  aad  a  C^a  dazc7ad  froa  Sflljgbat,  whiab 

—  miaia  Cba  baaaaieuz  o£  SQl  acttagB. 

~  Cbo  aafaptag'zaa  fatsala  aza  tiaaac  ca  daZaolc;  tbac  ia, 

~  Cbia  gaaozie  abauld  bo  iaacaatiacad  ia  tbo  aeepo 

—  aa  cao  elaaaa  iaz  SCIn^CbazJ^kg. 

9«a«rie 

typ*  WlcbJSolljrjpo  ia  liadlcad  pziraea;' 

Cypo  Wittbo«tJ(lSli_rjpa  ia  azsap  (poaiciaa  tango  O) 
a<  agl^aCaadazd.  flbarancag^typa; 
wltli  Saaceraa_VitbJ(ollJZaa«  T^itlnat  SflZjebaz_Sec_VBll) 
zagg^tWlfek  o;  ”  ,  ” 

vttii  Soaecioa  Witbe«icji«U.JZaao  (Valaa:  KitbJliiXI._T2rp«)  , 

Mcaxa  SOLjSkazJflM Jhill  ia  O; 

witb  teieciaa  Wicbo^  ZoUJJapaddadJBaao  (Valao:  WithJtaUJTjpo) 
zacazs  »QI.JSbazJ»ocJI«ai  ia  -O;” 
paakago  SQ&jCbazjD^  ia'*’  ** 

Auiacieia  VitbJIaU  (Valaa  :  WitbootJMUJEjpa) 
zataza  Vitb  Null  Typo; 

—  pzagaa  IKT.mj  (WitbJIaU) ;  '  ' 

ftuiociao  WitboatJIall  '^alaa  :  WitbJhxUjrypa) 

sacazs  WiCboM^NullJtypo; 
pzapaa  ZSUXI  (iricbam_Nall} ; 

Naaeclaa  WitbaaCjHaUJJapaddod  (Valaa  i  KiCbJfallJZypa)  '* 
zacaza  Witham  Nt^  Typa; 

~  pxagM  ZNZJNS  (WitbomJIaUJffapaddad) ; 
aad  SQ&jSiazjOpa;  ”  ** 

pri-raCa 

typa  SQLjSbaz(Xaagtb  :  SQZiJZbarJLaagCb)  ia  taeozd  . 

Za_Hall:  Zoolaaa  :■  txaa; 

Oapaddad^LaagCb;  SQl  Oopaddad^LaagCb; 

*aze:  S(SjCaiarJ(lot_Naii(l  ..  tangtb); 
and  raeecd;  ~ 

aad  SQ£i^Ciaz_Zkg; 
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C.24  Subunit  To__String 

ny  an  AmcLi.  hoai:  rhaTracSaj  sat 

—  thnt  is  SgL_Standasd.  ehasactag_Typa  is  Standard. Cbasactsc 
saparats  {SQZ,_CtMS_3kq) 

danctien  Ta^Strmg  (Vaiua  :  SOL_<T>;ar_KotJHuil) 
ratura  String  is 
bagin 

ratasn  (String (Vaiaa) )  ; 
and  7a_Strisg; 


C.25  Subunit  To_SQL_Char_Not_Null 

— *  assTsai  ng  an  ascii  hast  charaetar  sat 

—  that  is  SSZ^Staadard.Charactar__77pa  is  Standard. Charaetar 
saparats  (Sg:.^&ar^?kg) 

dunetian  Ta_Sgi_Ghar_JJort_Suii  (Vaiua  ;  String) 
ratura  S51_ttar_SetJiuil  is 
bagin 

ratara  (Sfii_CharJ»etJluU  (Vaiua) )  ; 
and  Ta__SQI.__Char”ant_SuiiT 


C.26  SQL_Enumeration__Pkg  Specification 

with  Sgi_Beaisaa  ?]cg;  uss  SQI.  aeaisan_?)cg; 
with  SQ!.jCharJ?)(g;  usa  SSi_ChJLr_?)cg; 
ganaris 

typa  S5Si_ZauasratiaaJSot_Huii  is  (O) ; 
paehaga  SgS  Zncaaratnan  ?hg  ~ 

is 


— ^assihly  Huil  ZnBaaratian  — — • 
tvpa  SCPCi_Xsiiaaratiaa  is  liadtad  privats; 

fisaetioa  »Bil^SQL_Zaq»acat. ian  ratara  SSLJtnnaazatiaa; 

—  psagM  aLnni  IvalXjSQlLJtsaaazatiQa) ; 

this  pniz  af  fancticns  aoowast  batwaaa  tba 

—  nail-haaring  and  aao-oaii-baart  ng  t}paa. 
ftaaetloa  Nithoat_»ali  (Vaiaa  :  is  sgZ._laMssatiaa) 

ratara  SQL  Trmaaratifin  Kat  lall; 

—  pragan  JXLim  (Nithaatjhili)  ; 

~  Vith_Vall  xaisas  lall_VslaaJberas  if  tha  inpot 
~  vaJLna  is  sail  "* 

faaetiaa  WithJhOl (Vslaa  :  in  SQLJEnnMsatisaJlotJtall) 
ratara  SQLJbiaasrstiaa;  " 

—  pragas  VOSSt  (Withjtall) ; 

pseendara  issign  ( 

Laft  :  in  eat  SQL  XnaMsation;  Sight  :  in  SCL^faqaaratian) 
— >  pra^w  TVT.THK  (Lsad^); 

^  Legiosl  Opasatiaos  — 

—  txpa  X  tjpa  Bi>  Boelasajwith_naknewn  ~ 
thaaa  fanetiaas  iaplaaant  thraa  wslaad  logie 

—  ij;  aithar  i^at  is  tha  noil  walaa,  tha  fanctioos 

—  rattan  tha  tatth  walaa  OlOClQfffl;  otharwisa  thay 
~  parfosa  tha  indicated  eoapsrison. 
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ftiocxior  ?o_Stsiag  (V*iu«  ;  SQtjSua:) 

c«t  icn  Sts^aij!  ~ 

£uaszi.oe  ToJSaptddtd^Sts^aq  (Valua  :  SQI._Qi*r  Hoe  Hull) 
roeusa  Striag;  ~  ~  “ 

-•iaceion  ro_0e?«<i<l«<lJStj:ia9  (V*lu«  :  SQL_Ciar) 
raeusa  Stria^;  ~ 

“  tHilH2  (?a_0seaddad^Stsia9)  ; 

~~  t^a  ZH1.SC2  «oeka  £os  3G7S~ juneeloaa !  I 
iaaceioa  Ta_SCl_CiarJloeJlttli  (Valua  :  Striag) 
raeasa  SQLj£jar_Hoe_Httll; 
fsMceioa  To__Scr_C:har  (vXlua  :  String) 
saeura  SClJcSur; 

—  pragma  aiilja  (5o_SCI.J5iar)  ; 

••aaeeioa  Oepaddad^laagei^  (Valua  :  SQL_Char) 
raeura  SC2^_0apaddad_Siaageii; 
pragma  Sn.:»  (Ospaddad_Laage)i) ; 

procadura  Aaaiga( 
loft  ;  out  SCLjChar; 

JUgae  :  $QZ  Cilt 

); 

—  pragma  (laaiga); 

'*'*  Suaaeriag(x.k,a)  raearaa  t^a  aubaeriag  od  z  atareiag 
~~  as  poaisiaa  )e  (zalasraa  to  1)  arsk  laogsk  a. 

~~  raearaa  null  aalua  if  x  ia  null 

saiaaa  eaaasrarat_azroz  if  Stars  <  1  os  Langsh  <  1  os 
Stars  +  Xraagst  »  1  >  x.Langtk 
±uietroa  Subasrrag  (Valna  :  SQt^^Cias; 

Stars,  taagst  :  SQL^CSiarJtiaogsit) 
satusa  SQtjShar;  ** 

—  pragma  ZHLiJOt  (Sutoatsiag) ; 

_  "S"  catusaa  aall  if  aishar  paraaatas  ia  aoU; 

~  ethaswiaa  parfosma  oeoeataaatiM  ia  tha  saoal  way, 

—  psaaasTiag  all  hi  an  Ira » 

may  saiaa  oaeatsaiat_asses  iaplieitly  if  zaaalt  ia 
~  too  larga  (i.o.,  graatas  thaa  SQi  chas  Loagth'Laat 
faactioa  "S"  (Z«ft,  Sight  ;  SQljaar)  ”  “ 

satusa  SQL  Chas; 

~  pcagma  an.rig  (”S*); 


—  Logical  Opasattnaa  — ' 

~  hypo  Z  tjpa  a»  SoolaaajaithjuJcaoaB  ■— 
tho  noapariaoa  opasatasa  satusa  tha  boolaaa  valua 

—  010310101  if  aithas  pasamatas  ia  Ball;  othasviaa, 

'**  tha  no^asiaiia  ia  doaa  ia  aooosdanna  vith 
~~  ZliSZ  ZS.US'ISSS  pasa  S.U  ganaral  sola  5;' that  ia, 

tha  ahostas  of  tha  tao  atsiag  pasamatasa  ia 
~~  affaetivaly  paddad  vith  hlaaka  to  ha  tho  laagth  of 
~  tha  laagas  atsiag  aad  a  ataadasd  Ida  onagiariaoa  ia 
thaa  mada 

fsaetioa  Zguala  (Laft,  Sight  ;  SQLJlhar)  satusa  loolaaajNith_aakaava; 

! 

fnaetioa  Zoejlgaala  (Laft,  fight  :  SQLjChac) 

satusa  loolaaa  with  Oakaova; 

**>  psugaa  TZL7W  («ot_lg0Bla> ;  "  '  " 

^taetioa  "<"  (Laft,  fight  :  SQLJChas)  satUA  foolaaa^vithJDTakaava; 

—  psugaa  Z2ILZ2CX  ("<-);  “  ” 

fuaetioa  ">"  (Laft,  fight  :  SQLjOas)  satusa  Boelaaa^withJDtakaoaa; 

—  pragma  SILSa  (">*);  ” 

fuaetioa  ”<■"  (Laft,  Right  :  .SQLJChas)  satusa  Boolaaa_vithJDnkBO«D; 


os»x 

DC 

PU<’21474a3C-t8 

SOSCSM 

DC 

X'CSOOOOOO' 

VXSCCV 

DC 

X'OOOOOOOO' 

POSZCSM 

DC 

x'rooooooo' 

zzxo 

DC 

P'O' 

om 

DC 

P'l' 

SX7Z2V 

DC 

P'15' 

ntrrwo 

DC 

P'32' 

MOZ.VXX 

HP 

0(0,2), 0(0,3> 

M0Z.V2X 

HP 

0(0, 2), 0(0, 4) 

DXVXSV 

DP 

0(0, 2), 0(0, 4) 

z:<s 

ADASC7 

C.22  SQL_Char_Pkg  Specification 

wltii  SQ]<_SyBCaa;  i>a«  SQZ^Sytmm; 

wxtlx  SCl>_Soolaaa_?kf;  ua*  SQXi^JSoaXaan^JPk^; 

wxtli  SQL  SkAosUsd; 


paeka^a  SO^_C>;ar_?fcg 
ia  “  “ 

a\tbevp«  SGl_CurJlaa?sk  is  oasasal 
saaga  I  ..  ifiUCC3SII2t; 
at:bevpa  SG:;_Ospaddad_taagdk  ia  aatssal 
sasga  0  . .  iGUCCSUZS; 

«ypa  SCI.j2iar_!Iot_Hnll  ia  aa»  SQt^Sftaadard.Char; 

t5pa  SCXij3ia»(taagsk  :  SQtjSww^Uagtt)  ia  liaiSad  privata; 

ftweeiaa  SttIl^sgi>^e!MX  sacara  SQLjSiaa; 

~  psagM  airSiX  Ti*gii_«Otj^a’f)  / 

»  tka  amatt  tkraa  dnaetiaoa  oeoract  bataaaa 

—  aoll-baasiag  aad  aoa  aalX-haarlng  t}paa 
~  1(i.tk«aC.JI«U_>aaa  aad  irX«iiJhxU_Saaa  ^ 

iararaaa  (aad.  aoUL  rmlaaa) 
aa«  alaa  SQL  ttar  Opa  gaaagia  paakaga  balaw 
daaoeiaa  WitbJ^^JlMC7alaa  :  Sg&jauxJtotJtaU.} 
racaca  se&jekar;** 

—  pragaa  niSiMI  (lUth  MIX  Saaa) ; 

.  >-  WlthaodJtaU^laaa  aad  Wltkaat JhiUJtaaaJIapaddad  xaiaa 
attll,,^Xsa'"acsoc  aa  th*  aolX  lapat 

Xaac&iaa  ittha«JlaU_Baa«  (Taloa  :  SaLj:kas)  ra«ara  SQ&_eharJloejh>U 
pxagaa  CfLUtX  (WitlM«e_Mall_Baaa) ; 

»  Vltkoa&JIalXJIapaddadJuaa  xaawaaa  trailing  blanica  Xraa 

—  tba  i^ot  ** 

foaetXaa  WithanfcJtaUJJapaddad^BaaaCVaiBa  :  se£._Cbac) 
raCaxa  SGX  Char  Vat  Halit 

—  pxagaa  uSsot  OfitiattJtaXXJTapaddadJtaaa) ;  ,  . 

~  aalaa:  tapaddad  taagthTx)  ■  ■  ■ 

—  •  WltboBt JUmJgapaddad^maaa  (x)  *Xaagth 

—  botb  Xaaetieaa  xaiaa  aaXl^‘ral«a_axtat  If  a  la  aoU 

—  tha  aaxt  six  foaetiaaa  ooa^att  batvaaa  Staadaxd. String 
•—  tppaa.  aad  tha  *Qt.  Otar  aad  SOX^Qar^Hat_RaXX  Lypaa 
ftaetloa  7a_Stxiag  (VaXua  :  sgli_etax_VetJlaU) 

ratasa  String; 
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~  ^VP*  Digl%  i«  piekad  «o  ba  aa  iocagar  ~'/p*  wxtb  a  ranga 

—  Shae  will  forea  Cha  Xda  eo^i^as  Co  pick  a 

~  pra>da2iaad  iataga:  k^pa  fxoa  paekaga  Standard. 

typa  3igit  ia  zanga  -(2«*7)  . .  (2««7)-l; 

tka  followiag  sbjact  ia  daeJLarad  ao  that  tba  trua  azsa 

(ia  actual  aizabar  o£  bzta  aiioeatad)  ia  aaaignad  to  tha 
"atsa"  ob^act,  zaekar  than  tha  ataabar  of  blta  uaad  of 
*  tboaa  wbieh  aza  alloeatad.  Xa  otbar  wezda,  uaiag  'siza 
— *  oa  tba  t^a  Digit  ytalda  4  bita  (nusbaz  bita  uaad) , 

—  whazaaa  uaing  tba  'aiza  oa  "objaet"  (of  t^pa  Digit)  yiaida 
8  bita  (auabaz  bita  aXlocatad) 


objaet  :  Digit; 

—  aiza  ia  tba  auabaz  of  bzta  uaad  bv  aaeb  objaet  of  typa  Digit 
*—  it  ia  Uaad  ia  tba  eaiculaczoa  of  HbX_S:3  (}>alov) 

aiza  :  eonataat  iatagaz  :«  objaet'  azza; 

~~  Mix  SZ22  ia  tba  auabaz  of  array  poaitiooa  naadad  for  tba 
MaxJDaezaai  typa  baiow 

aizea  aaeb  30  digit  can  fit  iato  4  bita  of  atozaga,  tba 
total  auabaz  of  bita  can  ba  caieulatad  by  HiUC_DICZ?S  *  4; 

**-  tbta  zaauit  ia  dizidad  by  tba  niaibaz  of  bita  tbat  aa  objaet 
'**■  of  typa  Digit  viii  eomziaa,  which  yiaida  tba  auabaz  of 
*■*  array  poaitzeaa  aaadad  for  tba  30  ataabar 

tba  zaauit  za  iaeramaetad  by  oea  to  aeeemodata  tba  aiga 

taxjszzz  :  eoaataat  iatagar  :«  ((4  •  (M«C_S2s:rS) )  /  aiza)  +  1; 

MaaJDaciawii  ia  tba  array  typa  dafiaitioa  uaad  by  tba 
~  SCItJDaeuaaiJHot^Huii  typa  dafiaitioa  (baiow)  to  aiioeata  aazianza 
~  atozaga  for  ita  ]K3  waiua 

typa  Max^Oaeiaai  ia  array  il..iaXJtiZZ)  of  Digit; 

SOJOaeiMljrot JtaU  ia  tba  Ada  BO  typa.  Zt  ia  eeapriaad  of  a  80 
Taiaa  ahieb  Maidao  ia  aa  objaet  vbieb  raaartraa  aoxiaMa  j 
~  apaoa  far  BO  raluaa,  and  a  aeala  wbich  iadieataa  haw 

■aay  digita  aziat  to  tba  right  of  tba  daciaa)  poiat  is  tba 
~  lO  walaa 

bypa  SQL_Oaeiaai^VatJiall  (aeaia  :  daeiaaX^diglta  :a  0)  ia  raoerd 
▼aiua  :  MarJOaijIaaiT; 

•■d  raeerd; 


^pa  SOb^Oaeiaal  Bat  Boil2  (aeala  :  dar1aa)_jiigita  :a  0)  ia  raeerd 
▼alua  ;  Hax^OaciMl; 

•od  raeerd;  ” 

tjfpa  BQL^Daeiaal (aeaia  :  daeiaal_jdigita)  ia  raoerd 
Za^Boil  t  boelaaa  :*  true; 

Vaioa  >  BQD^Daeiaal^llet^MnXi  (aeaia) ; 
aod  raoerd;  " 

a«d  BQi^Oaeiaal^Vkg; 
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g«a«ris 

typ*  :  daeiaftX__digiS«)  La  liaitad  privai:*; 

ftyp*  WisJiou6jSttH_typ* (•c»l«  :  (i*ciaal_digis«)  i«  llautad  pr:.7«ea; 
La^mcalm  ;  daciaa  l_dlgisa  :■  0; 

•>-sft__ai9a  :  Sign_rTi  a  ractar  :«  '  ; 

•~s\_iasa9xaj.  :  Itawri.e_se:la9  :« 

(1.  .dac‘-M IjdigtSa'  laa«-u>_ae«^a  >>  '  9' )  ; 
'i-sa't.__£smesioc^  :  Miaaagia^Sttjiag  :■ 

(1.  .ia_ac*ia  ■>  '  9' )  ; 

la*C^alga  :  Sign  r>!ar»csac  ;>  f'  ; 

la*t:_^iana9mL  :  Htauci.a_Stglag  :« 

(1.  .dacTaal^^digita'  la«tt-m_^aeala  a>  '  9' )  ; 
ia«n_£raeslaaal  :  ilusaci.e^Snsiag  :n 

(1.  .ia_aeala  ■>  '9'); 

^ti.'Six  fnaesion  Ia_rii_3aaa  (3dgi:c  ;  Mithoat_!laLl_j;vpa; 

Lataar,  Oppac  :  SCI»_Da«-‘iat_tlal;_MuII2) 
xaeurn  boolaas  ia  O;  ~  ~ 

5*aacsioo  Ia_:a_a*aa  {Kigne  :  »ishjjuii_?ypa; 

lawar,  Oppar  :  SCI._0aci3«l_SotJ9uil2) 
raeusa  boolaaa  ia  O;  ~ 

nitii  prneadura  Aaaig3_wxxb_^chac)e 

{laSi,  :  ia  one  Miebaue_Hull__Typa; 

Xigac  :  tfieboue_Hul^_^77pa; 

ZiOMC,  Oppar  ;  SQ:._3aceaaJ._tlee__Mtii,12) 
ia  O; 

nixix  peaeadusa  Aaaign  with,  shack 

“(iait  :  ia  one  *dieh  Moil  ?ypa; 
aighe  :  Wish  Httii  ^Vpa;  ~ 
lioaas,  Oppar” :  SCiJjiciaalJIoeJJttliZ) 
ia  o; 

wieh  Snaeeioa  7o  SOI,  OaeisaiJtoeJIttUI  (Vaiua  :  Wiehoue  HnU  T^a) 
raeasa  SQtjsJ^dall  HoeJInili'u  O; 
with  iaacssioa  tojJClJJaciali^HotJJum  (Vaiua  :  WtthJIttUJCypa) 
raeasa  80Zi_0aciai^  H<rt:J»uil2“’ia  O;  “  *’ 

with  2naesioa  7ojS0];_0aeiaaIJfotJlaU  (Vaiua  ;  SCL^Daoi«alJ>eeJlnll2) 
ratasa  Hithoae  Wall  ^pa  ia  O;  ” 

with  ftiaeeiea  To  SW  Oaeiaal'  (Valaa  :  SQL  Oosiaol  Wet  Wull2) 
ratasa  With  iou'typa  ia  O;  ”  ~  ” 

pocltaga  SQZ.J>a«iaal”opo  Xa 

preeadssa  Laaiga  (Left  :  ia  eot  Withoot  Wall  ^pa; 

Wight  :  Withoot  WaU  Typa) 
pcoeadara  JUaiga  (Left  :  ia  eat  With  ioU  Tjpa; 

Wight  :  WithJtaUJ^^);” 

~  rrti^a  TWT.-ma  .  **  " 

Aioetiea  Za^Xa  (Wight  :  WithoatJtaUJCJpa) 
retosB  beelaea;  ~ 

*««*weioa  Xa_ta  (Wight  ;  WlthJWoUJTjpa) 
retui  1  beelaea; 

~  pragaa  IWIIWE  (la_Xa)  ; 

ftnetiea  Withjtall  (Valaa  :  Witheot  WoU  Typa) 
aatoa  With  WoU  Tjpa; 

—  pragM  zaLXn(Wieh  Wall)  ; 

Waaotiea  Withoot JhiU” (Valaa  :  WithJtaUjtjpa) 

XotosB  Withoot^WollJEVpa; 

~  pro  gat  XBLXSW  (Witheo^WallJIJpa)  ; 
eod  SQLJDaeiaeljOpe;  ”  ” 

psi-rata 

'*'  the  ragoisMaat  hare  ia  to  psevida 

~  at’  least  oaeogh  apnea  far  sIm  ear  hi  na  swpsaaaatatiea  o£  the 
*"*  SCL_paeiaal  Woe  Noll  oparaoda. 
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£uaeeieo  ?o_SQl_aoubl«_?r«eiaioBj|loeJlnli  (Higiie  :  SCL_D«ci3*i) 
t«ea=a  SCL_^9oabJLa_Jr«es.«ionJiet._HaLl;  “ 

~  pra9a4  SCIiC  (;a_SCL_paubla  ?;ac^aiaa_llae_MuIX)  ; 

^hiacelaa  7o_SQ:._Dot3tala_?saei.ai.M  (lU.9iit  T  SQL_Oac±aal) 
xatas  SCZ>_3attbla^?raciaxoo: 

~  prai^aa  HCiyg  <7o_^SC:.^0aabla_>raeiaian) ; 

SallswiAf  £une£loaa  eoo'rart  Ssom  Dacimal  to  String: 
function  Sa^Sssrag  (ILigiit  :  SQL_Daeiaal_Nerc_8uXl)  ratura  atring; 

£unetiea  To^Scring  (Xight  :  SCI  Oaeiaai)  ratom  acriag; 

--  pra^ia  ZXJSIZ  (ra_Stsiag)  ;  “* 

Saaetiao  Ta_SSl__eax_Sos._Httll  (Sight  :  SC>_paciaalJlet  Hali) 
tacssa  SCiJ£:as_5et_Sull;  “  “  “ 

2ai:etiaa  7a_SCt_CiarJ(ot_Muii  (Sight  :  Sg:._Dariaal) 
xatsra  SCZ>_S^as^Sat_HuiL; 

—  pngsa  aTlDB  (7a__SCIi^Char_Sat_Htiil)  ; 

Taaetian  7a__SCl_Char  (Stght  T  SC^^Daeiaial)  ratata  SCL_Chas; 

—  pzsgaa  SiLSS  (7a_SC3.^Char) ;  ”  ” 

~~  tha  Saiiawiag  faaetiana  ratasa  tha  laagth  ai  tha  atring 
Taina  xatasaa4  bv  tha  *7a^Striag*  fanctian 
•  7-aettea  Width  (Sight  :  SQZi_Oaeiaal_Wet_HuXi]  ratura  iatagar; 

*-**  Tha  faiiawtag  funetiaa  raiaaa  tha  Muii_Vaiua_Zrrar  axcaptiaa 
an  tha  aull  input 

Taaetiaa  Width  (Sight  :  SQt_Da<?:»al)  ratura  iatagar; 

~  pragaa  22.20  (Width)  ;  “ 

—  Tha  Tailowiag  Taaetiana  Ispltmmat  acaa  ad  tha  Ada  Arrtrihutaa 
~  ad  tha  3CS  typa 

—  Tha  aabar  ad  BO  digita  badosa  tha  dacfaal  point  der  tha 
~~  typ*  ad  tha  gt7aa  ah;aet: 

duaetiaa  Zatagrai^Oigita  (Sight  :  SC!>_PaeiaukI^Bat^Moll}  racssn  daeiaaljdigita 
duactiaa  Zatagrai_Digita  (Sight  :  SQA^Daeiaukl)  ratura  daaijaa  l^digita ; 
pragaa  20.20  (2u:agraiJDigita) ;  _  " 

~  Tha  aaabar  ad  30  digita  adtax  tha  dac'ual  peiat  dar  tha 
~  t]pa  ad  tha  givaa  abjaet: 

dSBOtiaa  Sarnia  (Sight  :  S(3LJDaainal_Bat_>nH)  ratura  daeiaaljdigita; 
fnnctiaa  Seala  (Sight  :  SQL  Daeinal)  ratura  dariaal  digita; 

~  prayaa  2C2B(Saala]*; 


Tha  actual  nicdtar  ad  BC9  digita  badera  tha  darlaaT  paiat  der 
-**  a  glTua  abjaet  ad  a  glTuo  t]pa; 

daactien  7aca  (Sight  :  SQlJDaelaal^lat^Wull}  ratura  paaltiaa; 

^  Tba  dallaaiag  dunettaa  tha  Kull^Valaa_Xrzer  aa  tha  aall  input 

doactiaa  Para  (Sight  :  Sd^Dachaal)  ratals  paaitira; 

~  pragaa  XasUCton):  ”  ' 

—  Tha  nnnhar  ad  SO  digita  adtar  tha  darrinal  peiat  dar  a 
*—  giTaa  abject  ad  a  giTaa  tjpa: 

duactian  Sdt  (Sight  :  SQ&JDaeinalJtotJtall)  ratara  peaitiTa; 

She  dallcuiag  dunctiaa** rmiaaa  tba  Sall_Valaa_Sxrar  on  tha  aall  input  . 
danetian  Sdt  (Sight  :  SOTJ-irlnil)  ratura  peaitiTa; 

—  pragaa  2020 (Sdt);  ” 

daaet'iea  4 -  (Sight  :  SSS._Daelaal^let_lull)  rafai;  i  beolaan; 
fiiaai  I  lai  ** — *■( nadr  (Sight  :  SfltjTinal )  ratura  baalaaa; 

~  pragas  2a2o'5uehiaa_SaBada}  ; 

dunctiaa  MBChiaa_J>Taxdlaws  (Sight  :  SQl_Daeiaal_Wet_llall)  ratusi  beolaan; 
dunctieo  Maabina^Orardlava  (Sight  :  SCl_Daeinal)  ratura  baalaaa; 

~  pragaa  ag.r!ir*^«.-h< »»»  Orazdlawa); 
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raeasa  SCL_0*euul; 

—  psa^aa  ; 

Suoesioa  "/•*  (iait  :  SCt_0aCi3alJIo«_Suii;  Ri^hc  j  SQL_racJ»ot:_Huii) 
sacuza  SCL_0ae2AaX  Hoe~!Iull;  ~ 

faacaioa  "/"  :“sQLJ)aCi3ai;  aiijit  :  SCL_Iae_Hot_Hull) 

zacusa  SCZiJ3aeiaal; 

Saaesi.aa  ”/”  (Lait  :  SCLJ3ae:atal;  Si^he  :  SiZJCaz.) 

zaeaza  SCL_Oaeiaal; 

--  prasaa  ajllife  ('/") ; 

—  Sia  fallowuf  2aae:i.ona  ccnTar:  to  SCl_OaciaaI^i»ot_aull; 
taaez:.aa  ?a_SaL_Oaciaai_!lott_Htiil  (IU;i>S  :  SQl._Iat_Hot_Suii ) 

raaaza  SC«J3ae:jaal_!i9c_Hul^; 

■***  tiia  2alZo«s^9  iiaczi-oa  salz'ja  Caa«cniae_Zrraz 

i-£  aita  SvLjaoubla  ?raclai.oa_Hoe_Hall  valua  i«  too  lar^a 
to  ba  zapzaaaatad  ia  3CS  iazaaC 

iancsiaa  to_SQt^OaciaaiJIoe_Sali  {ais^t  :  SQI._3oublaJ?raciaiooJSotJ»ttli) 
sacaza  SCL_Daeiaal_Hee_>lulX; 

~~  ^a  fo^awta^  2aaeti.oa  razaaa  CaaBtsaijit_2zzoz 

***  i'  sbara  ara  aero  tban  iaX_3ICI?S  auabar  o£  diglta; 

i4  tbaro  4Za  tae  or  bozo  daezaal  poxaca; 

~  ~  tbaro  aza  two  ez  aaza  axga  daai^aae-oaa; 

~  i-£  tbaco  axxaca  a  ebazaetar  otbar  tban  '0'  ..'9'  or  ' 

—  or  '  'or  tba  0x50 

tba  ordar  oi  tba  cbazactara  xa  aoytbxz^  otbar  than 

—  ax^  daaxgaatioa  foUowad  by  tba  aosaaz 
Sisoctiaa  ra_SQI._3acxaaiJIoe_HtxLl  (aigbt  :  SSL_CbazJCotJlttll) 

zocazs  SSli_Oaexaal__Hoe__StxUL; 

—  pra^aa  3!.2ia  (ro_SQL_Dacijaai_^HotJlttU)  ; 

7!ia  S0H0WXZ9  dtaetxoaa  ceaTort  to  SQt_0acx=a2.; 

Susetboa  So^SQM^OacxaaJ.  (Sligbt  :  SQIi_IacJlet_iltxlX)  ratuaa  SCLJSaciaaJ.; 
Saaetbaa  7a_SCLj3aexaal  (%i9bt  :  SCL_Iae)  zataza  SQLJiacxaal; 

~  tba  jaUewia?  two  ftaeeboaa  raiaa  Coaaczaizie_J(rsar 
~  17  tba  SQlJDaabla_VraelaieB^!tot_lh^  valaa  la  too  Lar^a 

ta  ba  roproaoBtadTia  BO  dezaat 

Toaeslaa  7o_SQLDaclaBl  (Bl^bs  :  SgiiJBaablojrzaelaloaJfotJIaU} 
rataxa  SQIiJSaeiaal; 

ioaeblaa  TajSQL^OaexaBl  (Klfbt  :  SQLJoablaJgrariaioB)  rataca  SQIi_OaeiaukL 
~~  tba  loUawiaf  tse  daaetloaa  rmlaa  Caaatzaiatjlrzer 
--  17  tbara  ara  aora  tbaa  iaXJ)ZC27S  niadur  of  dlfita; 

—  17  tbara  ara  taa  or  aora  darlwal  palata; 

—  17  tbara  ara  taa  or  aora  al^a  doaipBationa; 

~  17  tbara  arlata  a  ebazaetar  otbar  tbaa  'O'. .'9'  or  '.' 

—  M  '  to*  tba  alga 

—  17  tba  ordar  o7  tba  ehararrara  la  aaytblag  otbar  tbaa 

alpa  daalqnatloB  7olIeaad  by  tba  wbar 
Toaetloo  7o_SQ£_Daelaal  (Sl^bt  :  SQLj3>arJtot_Sitll)  ratora  SCLJariBal; 
Toaetloa  To^SQL^Doelaal  (Xl^bt  :  SOLjSur)  ratuca  SQ£_DaeiBBl; 

—  pra^M  l5tI»(To_SQt_0aei»al); 

~  Tba  7olla«la9  Tnaetloaa  eooaart  Troa  BaHwaT  ta  Zataqar 
TaaatloB  7a_sg£_Zac_MatJlixLl  (Xlgbs  :  sgX.J»oelBal_«otjlBU) 
racara  iQL_1at  lot  ■ail;  ”  “ 

TaaetloB  7a_SQZ._ZBtJllotJlBll  (Blgbt  :  SQtJDaeiaal) 
racara  sgXi  ^  iot  iail; 

-»  pcagaa  ZXLzSl  (7o_Sff_Z8tJloejloll)  ; 

Taaeslea  7o_SQ£  Zat~ (lU^bt  T  St^  Oaelaai)  rataxa  SOL^Zat; 

—  prapM  zitZ«(7o_lQI,_Zac) ;  ”  “ 

~  Tba  7olla«iB9  TaaetloBa  eoBoart  Tzob  Bart  bo  I  to  71aat: 

Taaetloa  7o__SgL_Doubia_9eaelalaaJ(etJ(aU  (ftl^bt  :  SQLJSaeliuiJIetJfuIl) 
zataza  SCI,  Doabia  FraelaioB  Net  Moil;  "  '  ~ 
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—  ?r»5*»  SILSIZ  (I*_Ia_a*»*)  ; 

on  (VaXuo  SCI*  Doc^aol)  r«cu£a  booloaa; 

—  laLZJa  (lojiuil); 

i'-iaczioa  Noc_i(dl  (Vo^uo  :  SQL  Oociaoi.)  rocura  beolua; 

—  psacao  (Hoejhiii)  ; 

7b«  folJ,ow:Lsg  uoosy  or-Sbipoele  oporaeora  ara  pzovidad; 

SUBcSioo  (ai^bc  :  SCI._OaciaaiJlot_HuJ-L) 

ratasa  SCl._Oaciaai_Hoc_jruil;  ~  ~ 

Aacaion  (ai9ba  :  SC!*_J)aeaaai.)  saaaaa  SOL_Par;aal; 

-■Mcsioo  (Sijaa  :  SQI.J5aciaalJlo«Jluii)  “ 

ratasa  SCl_Oacia*iJloc_Hail;  “  “ 

iaacaioo  “(Xisba  7  SQL__Oaciaai)  raeara  SQI._Daciaal; 

*i=caion  "aba*  (Higba  ;  ScQaoT aa ’■  JtoeJIttll )  “ 

saaasa  SCI*  Oaeiiia  1  Morc_HuIl; 

f-aaeaaaa  "afaa"“(aigha  T  S0L_Oaciaal)  raeaaa  SCLJJaciaal; 

—  pra^sa  ac*aJZ  ("aba") ;  ” 

~  foUowaa^  biaazy  araabaacie  oparaaara  aza  pzoaidad: 

__  Tba  "4-"  and  lancaiona  zacuza  a  zaaula  wiab  a  aeala  a£ 

““  sax (laia . acaXa ,  Rigba . aeala ) 

tha  epazaezoa  pzodttcaa  a  zaattlt  tbae  ia  too  laz^o  to 
^  ba  zapzaaantad  ia  aa  ob^aet  tbaa  baa  tbia  aeala,  a 

—  Conaezai3t_Zzroz  wzll  ba  zaiaad 

iaactioa  (iait,  Rigbs  :  SCI*_Daciaa  IJIotJilttll) 

zatuza  SCl^Saczaal  Hot^Sttil”  ~ 

iaaetzoo  "+•  (Sait,  Ri^it  T  SCt^Oaeiaal)  zaeara  SCI._paeiaa).; 

—  pza93a  CCZSZ  ("+»);  ”  ” 

f*.saetiea  (iait,  Jligbt  ;  SCI*_paeiaalJ»otJlttll) 

zaf.iza  SCI*^OaeiauLl_ltoe^Mull; 

Action  (Saft,  T  SCL.Daeiaal)  zatbxa  SCtJDaeiaal; 

~  psaTsa  IJCraZ “  ■" 

~  innesiaa  zatszaa  a  raaolt  vitb  tbo  aeala 

~  Lait. aeala  ■¥  Right. aeala 

*"*  M  tba  zaanlt  ia  toe  largo  to  ba  zapzMaatad  ia  aa  objaet 
~  that  baa  tbia  aeala,  Ceeatzaiat  Izser  will  ba  zaiaad 
£sae«iaa  (loit.  Right  :  SQlJiaeiakLjfotJhai) 

zataza  MQL  Daeiaal  Vet  VellT  " 

^saetioa  "•>  (Sait,  Ri^  T  SQL_paeiMl)  xntaza  SQI>_Daeiaal; 

«—  Sbo  ■/"  itaetioa  rataxaa  a  zaaalt  with  aa  anoh  aeala  aa 
~  .poaaibla,  gitaa  the  aataza  of  tba  zaaalt 
~  ZS  tba  zaaalt  ia  tea  large  ta  ba  zapzaaantad  ia  tba 
~  '  tba  tndarlyiag  hazdwaza  or  ia  aa  objaet  with  ae  aeala,  ' 

~  er  if  aa  attoapt  ia  aada  to  diwido  by  aero,  tha 
~  Cooatzaiat  Rzzez  azooptiaa  will  ba  zaiaad 
Awetioa  ”/*  (ZaM,  Right  :  SQL  Ooeiaaljtotjhill) 
zetaa  sgi.  Oaeiaal  Vet  JlnUT  ~  ~ 

^Baetioa  V”  (Soft,  Ri^t  T  SaL_Daeiml)  zetttza  RQL^DaeLaal^ 

*""  Sba  fallewiag  aiTad  aedo  opazatoza  are  pzevidad: 

Ceaetioa  (Xaft  :  SOLJBoeiaalJlotJiall;  Right  :  Sab_Z8tJletJlail) 

zntaza  SQI*  Oaeiaal  Vet  Jlell;  ”  ” 

<Baatioa  ■•••  '~(laft  iTsObJ^aeiaal;  Right  :  SgpC._Zat_VotJtall}  .. 
zetaxa  SQL  Oaeiaal; 

faaetioa  ~(Zaft  :  S0C>J)eeiaal;  Right  :  SQZ._Zat) 

zatqzB  SQL  Oaeiaul;  •  - 

faaetioa  '’(Zaft  :  SgX>_Z8tJietJlaU;  Right  :  SQLJ)aeiaalJiet Jlell) 
zotaza  SQL  Oaeiaal  VetJlelT;  "  ~  . 

*wetiea  *»"  ""(Laft  sTsQL^tatJlotJlell;  Right  :  SQLJ>oeiaal) 
zotaza  SQL  Oaeiaal;  -  -  -  - 

Reaction  “(Laft  ;  SQL_Iat;  Right  ;  SQL_Daciaal) 
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—  vaJlaM 

£uacsi.aa  Zaco  saesxa  SQL_Oa<--Tl_Hoe_HuZ.l; 

^■mgsiiOB  Z«co  :*ess3  SCIi_3a«~7.-n«l; 

—  pca^aa  SCSIKCZaco);  “ 

^aacsion  Ob*  sacusa  SQL_t>*e. a* t Jitog_Hull; 

-uacSiBo  Cam  ratasa  SQI.~D*caaal7 

—  pSB^B  2IIJa*(Ca*);  “ 

SoLlaviaq  A**i.i;riiana  psacadus*  ia  proTadad  for  tha 

—  SQi_p*ciaaLJtotJlali  zyp*: 

~~  7!ia  foli,a«taf  ^si^saaaa  proeadura  raiaas  Caaaeraiae_Zrror 
— *  Zitm  ▼ala*  of  itl9^£  doaa  aoe  fall  wlaiila  dla  rang* 

of  lo«ar . . appar 

pcocadur*  A**i5B_'!»isi_C»*cie  (Zaft  :  la  ous  SCZ_Daeiaal_Hoe_Mull; 

iLl9be  :  SQZJ9*ca3al_Hocj(lall; 

Lowar,  Oppas  :  SCZ__0*eiaa  I_^Nqc_Hull2)  ; 

—  Tla  follawiaf  laai9a_«lsl_ehaclc  proeadara  will  ba  naad 
"  la  Ha  9*aarae  Aaarga  produead  la  SQL  Daeiaal_Opa 

SHa  proeadura  ralaaa  Ha  Cooacralac_2rrar  axeape^oa  If 
^  ~*  "^QhZ"  lapua  paraaacar  falla  ousaad*  Ha  raag* 

dafiaad  by  lowar.. Oppar 
procadtir*  X»#i5aJllH_Gi*cjt 

(Lafa  :  la  oua  SCZ_Cacla«l; 

Xlfiia  :  SQL_0*ciaal; 

Lowar,  Oppar  :  SCI*_a*CiaalJlot  JIuliZ)  ; 

ZSLLSZ  daal;a_j>aH_eii*ek)  ; 

~~  ^o  followlag  esoBarlaoa  eparatarr  ara  prowadarU 

•■i^ezioa  '•«"  (Lmit,  Rigba  :  SQZJ)*elaal_Haejllull)  rawara  ‘aoolaaa; 

funcaloa  *■''  (Laia,  Rigiia  :  $QLJ)*ciaal}  rocura  boalaaa; 

—  pragma  SIZ2SE  ('*«■’}; 

Caacftlaa  Zquala  (Zaft,  tigha  :  SQt  Oaelaul)  roeusa  Boelaaa  HIH  Oakaowa; 

—  pragma  rszantffgaala);  “  - 

foaeHem  Xa«J^aala  (lafl,  Right  :  SQL  Oaeiaal)  ratusi  Boolaaa  With  Oakaows 

~  pragiaa  ZSLSaoiotjUiBaXr);  •  ~  -  - 

*<*  (Loft,  Right  :  SQLJBaeimal^Vot^Hall}  rotaxr  haoXoaa; 
foaetiam  "<■  (Loft,  Right  :  SOL^^ciMmlT  raftnm  boolaaa; 

^oaetiaa  "<*  (Loft,  Right  :  SQL  Ooeiaal)  rotors  Boolaaa  With  dakaoma; 

—  pragma  2Xtia(-<-); 

<aaetiaa  *>•  {Loft,  Right  :  SQL  Ooeiaal  Ret  Rail)  rotaxa  keoloaa; 

Aaaetiom  (Loft,  Right  :  SQLJiooiaalT  roHxs  boolaaa; 

^waetiea  ”>■  (Loft,  Right  :  SQLJJoeiaal)  rotara  BoolaaaJi.H  nnhaowa; 

~  pragma  ZRLZRB(”>”);  ”  -  - 

^Baetlam  *<■"  (Loft,  Right  :  SQL  Booiaal  RotJloU)  rotara  i  oloaa; 

foaotioa  "<o*  (Loft,  Right  :  SOLOoeiaaiT  roHra  boolaaa; 

foaetiom  (Loft,  Right  :  SQLJioeiaal)  rotara  InnlonJT'  tijhlnnan: 

—  pragma  ZRLZRB(*<a>) ;  ”  “ 

taaetiaa  >>■"  (Loft,  Right  :  SQLJ>oeiaalJlotJlaU)  rotara  bi^olaaa; 

Rtaetioa  (Loft,  Right  :  SQLJ)oeiaal)  rotara  boolaaa; 

Rraetiom  ”>o*  (Loft,  Right  :  SQL  Ooeiaal)  rotors  Roolaon  W.  v;  Oateooa; 

~  pragma  ZRLaBC^*);  ”  “  “  . 

~  Rba  folloviag  fnetiooo  aro  aamborahip  tooto 

the  walao  of  tho  object  io  tooted  to  aoo  if 
***  if  it  fatlo  withia  tho  raogo  of  L^or..Oppor 
Awetioa  Zo^ZaJUoo  (Right  :  SQL  Oooiaaljfot  Roll; 

~  Lovor,  Oppw  :  SQL^Saoi^^RotJhU'Z) 

rotara  boolaaa;  —  —  — 

foaetioa  Zo_ZaJUo*  (Right  :  SQLJDoeiaal; 

~  Lower,  Oppar  :  SQLJ>*eimalJletJlBll2) 

rotura  boolaaa;  ■  ”  ” 
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SCi_Ooubi«_?=«ei«iooJloeJIuli  (Witiiou«Jluii_;rsp«'  lASr) )  ; 

•ad 

•ad  SCZ,_J>ottbl«_^?r*e^aioo^Caa; 

•od  SCLJDeubl«_?raeiaioa_?k7; 


C.1 8  SQL_DecimaI_Pkg  Specification 

wi.t^  SGL_Bool«aa_?k9;  oaa  SCX>_Boolaaa_?k9; 
wi-Sb  SQL_Znt_?>C5;  «••  SSl_::s'=”?Jes; 
wls^  SQIi_ChasJ?k;;  aaa  .SQI._C&ar_?k9; 

wi'tk  SCt_DattbI«^?r*e^iaa  ?k7;  «••  SClJPaabla^?raalaiaa_9k;; 
jMCka^a  SCI,JDa<iij=ai_?k9  ia  **  ” 

KiUM9ZS:7S  ia  ‘nyl  ■■an~»r'‘nn  da^iaad 
—  Zt  sapraaaosa  tk«  acaba:  of  di-^laa  thac  eaa  b« 

—  acarad  ia  tk«  cadaslyiaq  hasdtrar*'  a  raeraaaacasioo  of 
a  BC  ausaar 

1£*X^0:SZ7S  :  eanacaas  iaaa9«7  :•  31; 

aubaj^  dar-  -al_digiaa  Lm  aaaaral  stnqm  0 ,  .MX^ZGZTS; 

ftvpa  SCl_3ac:.-.aI^Hoa_MBl.l  (acala  :  daeiaal_di.7i.aa  ;•  0)  ia  liaiiad  p=2.7aea; 
%ypa  SQl._Daeiaal(aeara  :  d*ciaal_di7iaa)  ia  liaiiad  privae*; 

tKhtyp*  Htsaasic^Ckaraesar  ia  Ciasaesar  saag* 

*ypa  iliaiaeie_SS7ia7  ia  assay  (daciaal_di7isa  saag*  •O)  o2  Htaaasie_Chasaesa 
«y?*  Siga^Ckasaesax  ia 

— >  tka  Sellawiag  typa  ia  tUMd  2os  pozpMaa  •£  esaatisg  qmnmzLe 
■•aaigs  aad  ia_ia  £saetiaaa....00  BC?  OSZ  9CS  7SK  to 
esaaCa  tka  abatsaes  doaaina. . » 

Cy^a  Sgt_paciaaljletjlall3  (aeala  :  daesaaljiigita  :■  0)  ia  liaitad  psiTata 

gaactiog  7o_SCZ_paeiml_Sat_aaIl  (Talaa  :  SQI>_paeiaal_Bet_Ball2) 
satosa  — ii — 7  Bat  Boll; 

faactiaa  Xo_S^_paeiaaI  (viana  :  SSt._0aei«aXJIetJlall2) 
tatazB  SCL_Baeiaal; 

fBoetiaa  Sa  SC?_DaeiaMl  BotJtaUB  (TaltM  :  sgZ'_OaelaMlJI«eJlaU) 
cacasa  Siaeiaal  lot  iiai2; 

fanfftiaa  7a_SC?[j^aelMXjto«Jtall2  (Valaa  :  SObJIaeiBal) 
saCBca  SCm  nawiaal  Bat  BallB; 

—  pxa^M  ZBL»(Tajl«_pa«iaalJtotJtall2}; 

—  tkia  Boaetiaa  satasaa  a  aoU  aalaa  o£  tka  SQL^OaeiaMl  tjpa 
Taaetioa  Boll  SQL  fr-taaT  satasa  SCB>_0aeijBal; 

—  rsa^aa  ZBzBb  (B^_SQL_pw:iaal) ;  ~ 

Xka  f n1  ]  awl  ng  Baaeeioaa  shift  tha  aalaa  af  tha  abjaet 
~  aithaat  chaaging  tha  aeala.  Iffaetiaaly,  tha  epaxatiaa 

—  aatipliaa  tha  aalaa  ia  tha  abjaet  by  10«*Seala. 

—  Tha  foUaaiag  faoetioaa  saiaa  Caastra  i  ntjteres  if  tha  laft 
~  shift  eaasas  a  loss  af  aigwiftcant  digits 
faaetioa  Shift  (Valaa  :  SOI..DaciMlJtotJtall; 

Seals  :  iatagwe)  ««*asa*~sar._Pa<‘iaal JatJall; 
faaetiaa  Shift  (Valaa  :  SQLJDaeiaal;  ~ 

Seals  :  iatagas)  satoa  SQi_Daeianl; 

—  psagaa  ZBZfSB  (Shift) ; 


—  Tha  foUoasog  foaetioaa  satasa  ebjaeta  with  tka  apprapsiata 
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tan<szi,oa  :  SCL^tac)  racura  Boolaaa; 

—  prs^B*  SILZ2IZ  (Za^all) : 

eanGZ2.oa  aec_!lttll  (Valua  :  SQZ_Ia^)  xacusa  SooXaaa; 

—  SILHIt 

— >  SMa«  ^aacsiona  o£  elaaa  tv  >  boelaao 

—  aquasa  OMlQICim  with  TMSz/ .  x  la,  «hav  saeasa  SXOX 
~  only  ahaa  Sha  Staetioa  gaeaxaa  StOZ.  mmCKM  and  r>X^ 

—  ara  aappad  to  TiZSZ. 

faacaloa  *»*  (^a^,  lU^bs  :  S5i_Iat)  racara  aooXaaa; 

— '  pxa^aa  StI>2rE 

teaeslaa  *<"  (Laft.  Jb-sis  J  SSZ^Zat)  cacara  Soelaaa; 

— '  psafsu  SKiIMZ 

ftweeioo  *>*  (LoA,  3tl;he  j  raeasa  Soolaaa; 

—  psa^a  mLTilX  (‘’>‘*]; 

^aaeslon  *<•**  (La2^,  3tl9iie  :  SQiJLit)  xaaasa  Boelaaa; 

~  pxaqaa  3fLaK  ("<■'); 

£aaealoa  *>«"  Cxdt,  :  S«S._i:at)  raeaxa  aoelaaa; 

—  pra^aa  SC.:az  (">■*); 


—  thia  gaaarle  la  inacansjxsad  ooca  for  aaary  abacsact 

—  donaxa  baaad  oa  aiM  -TP*  Xot. 

—  tho  tSssoo  aubpra^raa  fasaal  paraaacaca  ara  aaaar  Co 
~  dafaalc  co  c&a  pragxaaa  daelarad  aboaa. 

—  ejias  la,  tha  pacicaya  ahoald  ba  laacaaclacad  la  Cba 
~  aeopa  of  a  aaa  clacaa  for  SQZJUtt^kq. 

—  Cba  awo  aeaual  cypaa  co^acbar  fora  cba  abaeraea 
doaala. 

~  aba  puspoaa  of  aba  faoarie  la  to  eraaca  faaealona 

—  wbleb  eoavase  baaaaao  eba  awo  aesaal  typaa  and  a 

—  psoeadura  vbrab  laplaaanaa  a  caoqra  eooacsalaad 

—  aaalfsaaac  foe  Cba  aall-boariag  cypa. 

~  abo  bodiaa  of  tboao  aobprofXaaa  aca  cal  la  to 

aabpcogsaaa  doelarad  abovo  and  paaaad  aa  dafawita  to 
abo  foeoeie. 

goaoxlb 

typo  Wlabjtalljcypo  la  Hwiaod  privaaa; 
typo  Wlabooa^mll  aypo  la  raapa  O'; 

«lab  fMoalatt  NltbJtall_aaao(V'aIao  :  $gk_J»tJhKjtuU) 
raaacB  wiab_>tilijsy^  la  O; 

«lab  faoatiao  UahoMjIallJMaofVialao  :  mabJtaU^^po) 
xoawea  SCP<JCac,SMjtaU  la  O; 

la<a  :  la  mat  KlabJKUJfypo;  U^ba  :  Uakjtalljtypo; 
rizac,  laaa  :  la  O; 

pookapa  SQL  XaC  Opa  la  ~ 

faaealaa  WlttJtaU  (VSalao  :  maboaajtoUJcypo) 
vaaaxa  1llah_JtaUjcypo; 

—  pcapaa  VOSjS  (Nltb  RaU); 

foaealoa  WlabowjtaU  C^aloo  :  »iahJtaU_typo) 
xoaaaa  Wlcbnac  itaUjCypa; 

'»  pxapaa  mus  (iiabam_aaU) ; 

pcoeodSKo  aaaljB  (Loft  :  la  oaa  WlabjadlJiypo; 

Slfha  :  ia  Wiabji^JCypo); 

>-  prapaa  WLIRE  (oaolpi); 
oad  SQLJEaa^Opo; 

pcivaao 

typo  SQLJtaa  la  roooed 

Za^MttU:  Soolaaa  :■  ano; 

VaXuo:  SQL.ZoajloajIuU; 

ood  caeoed; 
aod  saL_ZDa_rk9; 
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saiMa  eeaaesauit  arsac  L£  aot 

—  (Tirae  <■  tLxghxTK*  Ziaat) 
psaeadttsa  Aaai^a^aisii^ehaek  < 

:  la  out:  SQL  lae;  iU.9111  :  SQL__^«; 
risat,  Lars  :  SQL“loS_Mot__Hun)  ; 

—  pra9sa  atLrsi  (Aaal9aj»sSii_el>aek)  ; 

~  Sha  £oU.awiisuj  fsacslooa  iapXaaaat  Shraa  Taluad 

— ■*  12  alsitax  lapus  So  aay  o£  shaaa  fsaesisna  la  asU 
'*'*  Sha  2uaes^aa  sacuaaa  tha  aulX  ralua;  aShaswlaa 
~  Shay  paa^atai  Sha  ladleaSad  opacasloa 
— *  Shaaa  2saesloaa  salaa  ao  axcapciaaa 
2saesiaa  "-f  (Plghs  :  SQL^Ias)  sattisa  SCL_Zas: 

—  pca^  2IL=n  (■+■•);  “ 

2aaesioa  (lU^hs  :  SQL_IaS)  satusa  SQL_Ias; 

—  psa^aa  lilLna  ("-••);  “ 

2sacslaa  "aba*  (Pl^hs  :  SCL_Ias}  saeusa  SQL^Las; 

—  pragaa  StLSS  ("aha") ;  ” 

2aaesi.aa  "l"  (Lais,  Rl^hS  :  SQL_Iac)  rasuaa  SQL_XaS; 
paa9aa  SILZS  ("+"); 

iuaesloa  "*"(Lait,  Highs  :  SQL^^Iat)  sasura  SCL_Xas; 

—  psagaui  SCXa*  ("•"); 

isaesloa  **"(LaiS,  Highs  :  SCL_Iac)  rasuaa  SQL_XaS; 

—  psa^u.  IJILXsa  ("-"); 

iaaes2.oa  ’/"  (Lais,  Highs  :  SQL  lat)  sasura  SQL^^XaS; 

—  psagaa  :SLXSH  ("/"); 

isaesloa  "aod"  (Lais,  Highs  ;  SQL^Xas)  sasura  SQL_Ias; 

—  psagaa  XKLXHZ  ("aed"); 

^■»esioa  "saa"  (Lais,  Hrghs  :  SQL__^taS)  sasura  SQL^Xas; 

—  psagaa  2ILXX2  ("saat"); 

iuacsioa  (LaiS  :  SQL_Ias;  Highs:  XaSagas)  sasnza  SQL^Ias; 

—  pragaa  X»,rsa  ("»•*) ;  “  “ 

—  aianaXasloa  ai  'HOSZ  sad  'VHLCZ  Shas 
sasusa/Saha  SQL_Chac(^Rasjlall]  iaasaad  ai  aSslag 

iaaesloa  aOiSH  (ImM  :  sgL_Im_HasJlttIl)  sostara  SQL_C3>ar_MoS_HalX; 
iaaeslao  XXHSZ  (Lais  t  SQL~l8s7  rasaxa  SQLjShas; 
fusosloa  THLOX  (Lait  :  HQL''char_HosJHOLL}  sasara  SQL^Zae_HoS_Hall; 
iuaeslaa  7HL0X  (Lais  t  sgL^CharT  ratasa  SQL^Zas;  ~ 

~  Logiaa,.  ‘:>passtleaa  — 

~  X  sjpa  ■>  Baolaaa^^vlShjaafcaaam  — 

hhaaa  ioaeslaas  laplaMat  Shsaa  valaad  lagis 
~  li  iuthac  iaptR  la  Sha  aall  Tsiaa,  tha  iaaesleaa 
>-  rasaxa  tha  trash  tralaa  aaORMII;  aSbaxaiaa  Shay 
~  pasioaa  Sha  iadtoasad  aaapaxlaaa. 

Shaaa  ioaeSlaos  salaa  aa  axoapSiaaa 
ioaetlaa  Igaala  (Lait,  Pigt«*  t  SQL^XaS)  saSaxa  BaalaaajriShJgafcaowa 

)  # 

iaaoslaa  Rasj^aala  (Lait,  Highs  :  S<iL_ZBt} 

xaSasa  i  .  .'iaaajvlSh^JIIakDaaa; 

»  pxa^M  •gtl.TWI  (RoSJCg;aaaa); 

iaaasloa  (Lait,  lUgfaS  :  SQL^Iat)  xaSaxa  HealaaajidiShJHakaaaa; 

—  psa^M  ZHLXXI  ("<") ;  ”  . 

iaaesloa  *>"  (Lait,  light  :  SQL^^Iae)  xasass  Beolaaa^aiShJSakaaaa; 

— •  psa^u  THL7IH  (">");  “  ~ 

iaaetlea  "O"  (Lais,  light  :  SQL^XsS)  saSara  l«olaa8_«lShJSalBtatm; 

—  psa^u  XSLXII  ("<»");  ”  ~  ” 

ioaeslaa  ">«*  (Lait,  light  :  SQL_,Xst)  sasara  BeolaaajrithJBaJEaova; 

—  psagma  XHLaS  (">■");  ”  ”  ” 

Sypa  ■>  beolaan  — 
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funettian  ’xac”  :  BoolMa__wxth_<IaJcao«n) 

ratuxa  Bonlaaa^wxtli^OaJcaawn  La 

hatfLa 

ratsuza  (Laft  aad  aoc  or  (aoc  XtaSt  and  Right) ; 

and; 


>•>-  tbsaa-val  ■>  bool  or  axeaptioa  *■■*** 

faactzon  7o_^3oeiaan  (Laft  :  aealaaa_with_OBJcao«a)  ratasa  Boolaao  ia 
bagia 

if  Irafb  a  OnJaewa  than  raiaa  auii^Talua^oxror; 
aiaa  raCusa  (Iroft  a  Sna)  ;  ** 

and  if; 
and; 


thxaa-Tai  a>  bool  ~- 

funetioa  Za__;sua  (Laft  :  BooXaaa_with_Oa]eao«n)  ratnra  Boolaan  ia 
bagia 

raeusa  (Laft  a  fsaa) ; 

and; 

faacsion  Za_7aiaa  (Laft  :  Boolaaa^withJUnbaewn)  xatara  Booiaaa  ia 
bagia 

ratura  (Laft  a  Taiaa) ; 

aad; 

function  :a_OaJcao«n  (Laft  ;  Boalaaa^«ith_Oabaoan)  ratura  Booiaaa  ia 
bagra 

ratura  (Laft  a  Onkao'an) ; 

and; 

aad  SQL__Boelaaa_?Ieg; 


C.10  SQLJnt^Pkg  Specification 

with  SQLjItaadard; 

with  S4L_Be«iaaaJ7kg;  aaa  SQL_Bo«laaaJ?kg; 
with  S<S>_,Cbor_tkg;  oaa  SCLjChuJBkg;  ** 
^ekaga  SQL_Zat_Pkg  ~  ~ 


^fpa  SQLJCBt_aetjBall  ia  aow  SQLjKaadard.Zat; 

Vooalbly  **11  Xntagar  — 
typo  SQL.Xot  ia  Itadtad  priTato; 

foaetioa  kaU^saLJCat  xotara  SQL^Zat; 
psa^u  TKTiTW  ISBlljraL^Zat) 

~  tbla  pair  of  foaotiona  oesrort  batwaan  tho 
— *  anll-baaaiag  aad  noo-nall-baart ng  typaa. 

foaotion  Vitbewt  anU  Baao(Valaa  t  SQL^Znt} 
rotasn  BQLJtntJioc^Ma; 

->  psa«M  laLiai" (Hitboot  ; 

—  WltbJkOIJUao  saiaoa  iaii^alaa^lrror  if  tbo  ii^ut 

—  walno  la  anil  ” . 

fttsetion  »ith_lttllJUaoC7alno  :  B(9C.JZatJletJh*ll) 

zotnca  SQL_Zat;  ***  ' 

->  pragM  HILTW  (WithjiallJBaao) ; 

»  thia  preeadoro  iaplaaanta  raago  cihacklng 

—  aota:  it  ia  not  ■iint  to'ba  uaad  diractly 

by  application  progxaooara 

—  aaa  tha  ganarie  paekaga  SCL_Iatj3p« 
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—  TSItSSZ  CaC*); 

taaazs.on  "xoc"  Right:  :  BoelMa_with_t7a}eao«n) 

x«cum  BooImb  with_Oahao«n; 

— •  pca^a  CTLZ^B  ('xor”); 

—  thr««— T«i  ■>  bool  or  oxeapoioe  — - 

-uaetlaoB  To_3eolMa  (Lo^t:  :  Beolaaa_«ithJSakaewn)  xotasn  Beolaon; 
praipna  StLSS  (7a__Booiaaa) ; 


— —  thsaa-raJL  «>  booi  ~- 

funcsioa  Za_7rua  (I>a^  :  Boolaaa^with^OnJstoim)  rahuxn  BooXaaa; 

“  pra^a  EttlJOE  (Ia__Srt»a)  ; 

fusesioa  Za  FaXaa  (I,a5t  ;  BooIaaa^withJOoJeaowB)  raeura  Boolaan; 

—  pragma  zia.ZSS  (ZaJTalaa);  “  “ 

ianettioB  Za  Oakaowo  (LmH  :  BoaZaan^withJI7Bkao«a)  raoura  Boolaaa; 

—  pragma  glLUlX  (ZaJSnkaown) ; 

aad  SQZ._Boolaaa_?kg; 


C.9  SQL_Boolean__Pkg  Body 

With  SCte_2zeapr ioaa ; 

paekaga  body  SQL^BoolaaajFkg  ia 

Httll_Vaiua_3tsrar  :  axcapcioa  ranamaa  SQI.__txcaptiooa.Mttll^Vaiaa__Z=ro 

dttaetuaa  "Bat”  (Ia2t  :  3eeXaaa_«ith_0nkao«B) 
ntasa  8oalaaB_wath_0aJc>atm  ia 

bogia 

eaaai  Loft  ia 

whoa  tztto  a>  ratora  falaa; 

«boa  falao  •>  rotas  tsaa; 
thoa  aakaoom  ■>  rotas  aakaaoa; 

aad  eaoo; 

«ad; 

fnaetiom  "i^d"  (Zoft,  Right  t  BooZoaa_withJOalEaa«B) 
ntara  Boolaaa  withJOaksooa  ia 
bogim  ~ 

if  (Zioft  m  falao)  or  olao  (Right  •  falao)  thoa 
rotasa  falao; 

olaif  (Loft  m  OalmaM)  or  olao  (Right  •  anknooii)  thoa 
rotam  Uakaeom; 

olao 

xotaxB  Srto;  ‘ 
oad  if; 
oad; 

fanctioB  "or"  (Loft,  Right  :  ■oolaonjiri.thJBakaBoa) 
xotaxB  8eeloaa^«ith_QaJBioom  ia 

if  (Loft  a  Sxuo)  or  olao  (Right  o  Srno)  thoa 
rotaxa  Srno; 

olaif  (Loft  ■  QahoaoB)  or  olao  (Right  ■  Qokaooa)  thoa 
rotaxa  Vakaooa; 

olao 

rotaxa  falao; 
oad  if; 
oad; 
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—  pra9>«  2ttUI*(Z*_D«y_^ria«); 

faaersioa  Hac_Y««£_^Hoae^(y«lu«  :  SQL_CntarTaX]  sataxn  B«olaaa; 

—  ?r»5B*  litizaa (jloc_^1f«*r_MooeJ») ;  ~ 

S'Jacrti.aa  Xae_Oay’_J?laa  (V«lua  :  SQL_ZataETal)  racuxa  Boolaaa; 

— "  ?«*5a*  Cttan6~(Soe_0*y_5i3>a)  ;  ~ 

~  %h«  praeadora  Cussaat  raeusaa  tha  easzaafe  aysdam  Oataddaa, 

'*'*  ~a  pcae&aioa  o£  t^a  issue  Taxsabla 
procadusa  Cussane  f7alua  :  is  oue  SQt  Oaca) ; 

~  psa;^  aUSB  (Csrsaat)  ; 

'***  pcacadusa  Zxsaad  saesssa  tiia  ralua  at  eha  Righe  lapue  ofajaeS  trieii 
<^a  daeaeiaa  quaii^ias  at  thm  Lade  objace,  id  a  Taiid  daeaeiaa 
*''*  aaiua  ia  gaaasaead  by  eba  axsaaaioa  psocaaa 
psseadttsa  Zxeaad  (Vaiua  :  ia  oue  SQZ,  Daea)  ; 

—  psagau  ISiZS*  (Sxeaad)  ; 


'***  bbia  Taaasie  ia  isaeaaeiasad  oaea  das  aaasy  abaesaee 

SC^_3aea  domais,  aad  oaea  das  aaasy  abaesaee  SQt>_Iaeasrral 

—  dnma-n,  baaad  oa  eba  eypa  SQt_Daea_Hoe__Httii .  "* 

-~a  bwo  aubpso^aa  darssal  pasamacasa  asa  aaane  ea 

~~  dadauie  ea  eba  pSogsaaM  daeiasad  abova. 

*'*  ebae  ia,  eba  paebafa  abouid  ba  iaaeasesaead  ia  eba 

—  aeopa  ad  a  uaa  elauaa  das  SQL__paea_?)e9, 

— ”  “’•o  aceuai  eypaa  togaebas  dosat  eba  abaesaee 

—  decaT.n. 


puspasa  ad  tba  gaaasie  ia  to  esaaca  duaeeioaa 
wbieb  ees'Tase  baevaaa  eba  ewo  aeeual  typaa 
~  eba  bodiaa  ad  ebaaa  aubpsagsaaa  asa  eaiia  eo 
~  aubpsagsaaw  daeiasad  abora  aad  paaaad  as  dadauits  to 
eba  ganasie. 

gaaasia 

eypa  Wteb^HuH^jrypa  ia  lisdead  prteaea; 
eypa  Viebsue_ilttil_7ypa  is  assay  <pesieiva  saaga 
«d  SQL^Stands  ird .  assaceas^eypa ; 
wieb  psocadusa  Passa_Md  Asaigs_Basa 

(Zott  :  ia  ooe  tight  :  SQL  Data  Vot  Roil)  U  O; 

wltb  duaesios  Wteboaej«uU_Bsaa(Valaa  :  »itbJ*ttU_l5p«)” 

Soeuxa  Sflt_Oaea  Hoe  Hull  is  O;  .  “  “ 

paekaga  SfitJDatajSps  is”  ” 

p»oeado»a  >axsa_aadJUsigB  (iadt  ;  HitbJteUJSype; 

Higfat  :  Hiebadt^HaliJEype) ; 

—  pragaa  IHLIHl  (Sassa  aad  bsaiga);  ”  ” 

daaeeion  HieboaejittU  {Valal  :  Hitb  HuU  lypa)  >.  •  ’  '  . 

z«easB  Hiebott  HaU  type;  ”  ”  _J  ' 

~  psagaa  IHXJQIl  oiitboSeJhai); 
aad  SQtJJaeaJJps;  “* 

gaaaria 

tyP*  Wteb_Jhill_Oaeajrypa  la  1  laitad  psirata; 
feyp*  Wieb_Hull_IatasTal  l^pa  is  Had  tad  pslTaea; 

wleb  duaeeloa  Vius  (Zsdt  :  Hitb  HaU  Data  Type;  tlgbe  :  tOt  ZatasTml}''  ~ 
zatasB  Hitb  HaU  Data  T^po  U  o”  .•  ..7-  ■  -  •  •  - 

•itb  daaeeisa  Bias  (2#dt  T  SQLJiatarTml;  Highfc  ;  HltbJhOlJjata^ty^) 
zaeaxa  HttbJlaU_Data“Typa  ia  ■©•;  ”  . 

•itb  dnaeeioa  Miaas  ff-adt” :  Hltb_HaU_OaesJSyp«;  K.igbe  t  SOtJtatJirTai)  , 
zaeasa  HitbJIaU  Bata  is  O;”  . .  7  .  - 

•itb  daaceioa  Kiaas  "(ladeT  High*  ;  HltbJtaUJJataJCyps)  -  , 

satasa  Sgt^Iatarral  is  O;  ”  ” 

paeksga  SQt._Dsea^Iatajrnii_Ops  is 

faactioa  ’♦"“(Lade  ;  Hitb  HaU  Bata_typa;  Highb  :  Hitb  HaU  Zatasral  *ypa) 
satusa  WitbJ»uU_^Data7Typ«T  “  “ 

daaceioa  (tTdt  ;”HitbJHuU_IatasTaX  typa;  Rigbe  :  HltbJIaU  Bata  Typa) 
taeusa  Hleb_HttU_pataJCypa7  ”  -  -  - 
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Aunotuon  lUghc  :  tfl.th_lluii__Iat»rr«ljryp«) 

raeuss  Wtsh_Huii_D«e«_Jfyp«; 

^unesiaa  iu5h«  :  Hith_»ttll_D«t«_Tjp«) 

raeusa  Hi'Si»_Hull_Iat*rral_Typa; 
and  SC!>_DBta_Iataz-7ai_0pa; 

psivaea 

Uypa  SCL_yaar_DtiBbar  i*  Stjxq*  1C00..9999; 

itypm  SCIi^aeoeh_auabar  ia  zmxigm  1.  ..V2; 

«Vpa  SQL~day_oaiI>ar  ia  raaga  1.  .31; 

«ypa  SCX>^lMtix_auBbax  ia  raagm  0..23; 

cypa  SCt.^aiAuea_auaear  ia  szagu  0..39; 

cypa  SCI>_aa«ond^auabar  ia  raaga  0..39; 

«ypa  SCI>~fxaesaea_euaba7  ia  ranfa  0. .  (2**31) -1; 

«ypa  SCI.”ia«anrml_au«iibar  ia  raa^a  -{2»*31)  . .  <2**31)-1; 


«y?«  *CIi  Oata(rroa  :  SQt  Datatiwa_riald 

To  :  SCZ>_Dataeiaa_riald 

rraesieaai  :  pcaeiaaaa) 

ia  racerd 

ZaJIuU 

:  Beelaaa  ;■  trua; 

yaas 

:  SCL_yaar__auabax; 

aoath 

:  SQL_aaach_a«aBbar; 

day 

:  S5X>_day_atsibar; 

hour 

;  SCL^bour_BtsDbac; 

aaausa 

:  SQtTaJMW^aiaitomz; 

aaeead 

:  SCI>~aaeead_auahar: 

draetiaa 

:  scirisaetiea_auaba«; 

aad  xaeosd; 


typa  S6L  lataxraKTraa  :  SQl^^OatatiaaJTiald; 

~  imadlag  :  pcaeaaaoa; 

*0  •  i  SQX._pacafciM_riald; 

rrae«iaaal  :  psaeiaioa) 

ia  saaosd 

2a_MttU.  >  booiaaa  :■  Tsaa; 

beeiaaa  :>  Ssaa; 

SQi^iataxYmljataibar; 

sgT^iatarTal^a™**'’^* 

SQzTiataxvaJljBaabac; 

SOXt^istarral^a***^**' 

SQL^iac«nrai_aaBbax; 

•ad  raooad; 

•ed  SQLJSata^Vkg; 


C^1  INGRES_Date_Pkg  Specification 

aitdi  SQLjttaadaxd; 
with  sgs^tymf^am:  w»a  IBlJlyweaa; 
with  CaiMdax;  oa*  Calaadax; 
with  SQL  Boolaanjk^;  aaa  SOLJtoalaaaJIk^; 
with  SOL^Chut  fkg:  aaa  sgijChax^fkg; 
pMkagw  Statu  Data  fkg 
ia  “  ~ 

typa  SICS«U__eataJtoeJluXl  ia  aaa 

- Poiaaiily  Hull  Oatatiaa - 
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Package  SQL_Base_iypes_Pkg 

with  SQL_fil>j  r_?lcqr,  SQL__Xa«_?>c9,  SQI._Sw1  T  i.ntt_J?lcg,  SQ£_RMl_Vkg, 
SgL_Ooubla_?r*ci.«iaa_?)cg,  SOX>_D«ciaal_Pkg,  SQX>_StaDdard; 
packag*  SQLJta««_'7vp«a^Pk9  is 

packagt  Caaraesar_S«k  saaaaaa  S0L_St«n«1»rd. 

typs  SQt_Iat_^Hot;_HuU  Is  naw  SQL_IatjPk<r.SQI._li»tJlot_lliiU.; 

typa  SQl._Iat~Pk9TsQl._ta*7  ~  ” 

'packaga  'iQZ._^e^Op«  is  naw  SQX._Zac_Pkg.sQL_iDe_opa{ 

SQlTiiS^Typa,  SQl__IntJtoe3oli) ;  ~  "* 

aubtypa  SQL^Zas^Subejfpa  Js,  SQIi_Iae_Pkg.SOL_Zae,* 
subtypa  sgZ>_:^s_Nae_MttI.l_Subcvp«  Is  SQZ>_Xac_^Pkg.SC3X>_Z<>t_Rot_lluJ.I; 

typa  Sflt^Saui *  7.  *  nc^Mofc  Mull  Is  naw  SQL  Sawlllau  gkg.S0I.^Taa1  T  i  nt-  Hoc  Mull; 
typa  SQt_SMdiatJ-7f*  is  naw  SQt^Sall  line.JPfcg.SOL_Saw ?  7  i nt;  “  ** 

paekaga  SQL  SiaalT  inc^Opa  is  naw  SOL__Swal\rntt_Pkg.SOL_Saat  line  0p«( 

SQiT  Saa  1 i  rnTtyp^,  SQL_SMlLintJloe3“^) '  ~  ” 

SUtatypa  SQL^Sma  1 1  i  irc^Sttbuypa  IS  SOL_Sa>a  1 1  i  ns^Pkg.  S0L_Saa1  H  ns; 

SUbtypa  SQL^Saa  ’  1  i  ne^Mos_^Mull_SubCYpa  Is 

SQL^Sma ’ i  nt JPkg . SQL^Sma  1 1  ‘ nt_llott_Mull; 

typa  SQL^IUalJfoCjIull  Is  naw  SQL_IU«l_Pkg.SQL_RMl_MotJlaLll; 
typa  SQL“Ra*lJ?yp«  is  naw  SQl_Raar_PkgTsQL_a«ar;  ~  ” 

paekaga 'icL_RMl_Ops  is  naw  s^_R^_Pkg.sQL_R«al_Opa( 

SQlTiUai^Typa,  SQL_R«*I^Mo«3“^> ~  ~ 

SUbtypa  SCL^aalJssbeypa  is~SQL_R*al~Pkg.SCL_R*al; 

SUbtypa  SQL“R«al“M<»e_Mttil__Subttyp«  is“sQL_R«aI_Pkg.SflL__Raal_Mot_Mull; 

typa  SQL_9oublsJPr«esaiea_Mat^Mull  is 

naw  SQL_3oubla_?s«eiaioB_?kg.  SQLJ3oublaJPeaeiaioa_Nos_Mull; 
typa  SQL^OoublaJPsaeialaa^Typ*  is 

naw  SQLJDeubla^PsaeisMa^Pkg.  SQ£_pecbla_Psaeiaiao; 
package  SQL^Oeubla^PraelalaajOpa  is 

naw  SQL_Oeabla_7saelaioa_Pkg.SQL^DoublaJPceGiMaojOpa  ( 
sgXi^OeublaJPraeialoaJCyiM, 

sgX>^paabla_^Pr«eialoa_Mee_)lull)  ; 

SUbtypa  SQL JOoublaJragla ion__SBbtypa  is 

SQLJPoubla^PeaeiaioB^Pkg.SflLJoqhla^JPrar  iaiog  ; 

SUbtypa  SaL_Oeabla^Pc«eiaioaJKot.JHallJSubeyp«  is 

SQL_Doubl«^tr«icislaB_Pkg .  SQL^Doabl«^Praelsiae_Boe^Vall; 

* 

typa  SQL_eh«rJ>eejtaU  la  naw  sol  caw^Pkg.SQLjOMrJtoejtall; 
typa  SQL^CbarJTyp*  la  naw  SOL_Cbax  PlcgTsoL^Quir; 
paekaga  SQLjSax^Opa  la  naw  s^jQm  Pkg.W.CbarjOpaC 
SQ^Cba^TJpa,  SQL_Cba^ao*Th*U) ;  ”  ” 

aubtypa  SQL_Cbac_Sabeypa  1^  SQLjCbas  Pfcg.SOL_ttac; 

^aubtypa  SQLJSbarJfotJhiUjSubey^  ls~sgL_CbarJPk9.SCB.j:harjaetJtall;'' 

typa  SQL^OweiMljaocjIuU  is  naw  sgL_0«daua^Pkg.sgL_pMiawlJlotJh^;  ■' 
tyiM  SQL_p*e3jaal  S^pa  la  naw  SqLJaci»al^gkg.SCL_r>a«Tiwa7 ; 
paefcaga  SQL  Oaeiiul  Opa  is  naw  SQL  PaclaiUJkg.s5LJaciaalj3pa (  ' 
SQlTDaciaaLrTypa,  SQL^OariiwlJlotJhill) ;  ” 

.  aubtypa  8QL_0aeiawl_Snb«ypa  is  SQL  Oaeiawl_Pkg.SOL_Daclawl; 
aubtypa  SaL~OaeijBal~iloCjlttU_Sttbt^  Is  ^  ~ 

SOL*  Daetaaf  Pk^. SQL 'OaclMl  Bat  Ball; 


Package  SQL_Standard_i:ynamic 
with  sgii^Staadard,  S0Xi_0*eiaaJ.__Plc9; 

UM  SOIijStaiwUrd,  SpLJO^ci ■■  l_Pkj; 
paekag*  SQIi_Sa«nd«rdJyii— tic  Is 

typs  ixcaadadjCassos^Typ*  is  impl0m»ntaiion  dtSiMd: 

ty^  lscsndsd~stst  —sntjgypc  is  impl»m»nation  dtSntd; 

ty^  SQZ>__DynaiL,e_Ost««y^a_BsM  Is  rsngs  impkmtnation  d$fm»d: 

Nayb*  MttU  Zadio  :  constant  Zadisstoc  Type  :>  Z; 

~  ->  ^ua  of  SOUreZXUUC  is  nulla  alloaad 
subtype  Mttll_Zadi  catioB  Is  ZadieacocjEypa  range 
ZadiescosJIype' Tixse  ..  -1; 

--  Tala*  e£  indicator  iS  toIuo  ia  null 

—  typos  to  dooaribo  ooluoa  naaaa 
SQL_CalnanJHaaoJboa9th  :  constant  :*  18;  ~  sat  in  SQL2  standard 
subtype  SQLj:ol^Jt»mm_L»agth.JSyp*  Is 

poaitlea  range  X.  .SQIi_Colu«aB_Maaa^laa9th; 
subtype  SguaHEJSypa  is  Cbar(SQL_Coluan_Naaa_Iiasgth_Typa) ; 

~  Tbaaa  ooastaata  eaptura  tba  aaeoding  ot  SQX.  Typas  as  Intagars 
—  aa  givaa  by  SQZ2. 

Het_Spaei2iod  :  constant  SQL_Oyaaaio_Datatypas_aaao  ;a  0; 

Dyaaare^Char  :  constant  SQL_Dynaaie_patatypaa_&aaa  :■  1; 

DyxiaHie_tttaMrle  ;  constant  SQIi_OyBaade_Daeatypas__Baaa  :a  2; 

OyBaade^Daeiaal  :  constant  SQI>__Oyaaaie_patatypas_&aso  :a  3; 

OyaaBu.e_Zat  :  constant  SQIi_DyaaaLie_Datatypasjaaaa  :■  4; 

PynaMic^twal  Xiat  :  constant  SQL_Dyaaiiie_OatatypasJBaaa  :•  S; 

OyMUBlc^jrioat:  constant  SQIiJC>yna*ieJ>atatypaa_Basa  :■  8; 

Dyitaade^Ilaal  :  constant  SQLJ>yaaaie__paCatypasJ8aso  :a  7; 

OyBaar^DoublaJPcaeisioa  :  constant  SQ£,JDyaaade^DatatypaaJ8aaa  :a  8; 

aubtype  SQZi_pyBaaioJDatatypas  is  sgXi^DyaaaicJDatatypaa^Basa 
range  Mat  Spacifiad  . .  Oynaadic  Double  Procisioa; 

“  •  I!  ” 

—  aaooaa  types  <or  ;eeapoaaats  of  SQL_DyaaBie_Paraaacar 
type  Chas^toeass  iaaeeen  Char; 

type  Daai  aa  l_Jtoeaas  IsaocaSi  SQZ>_OaeiaalJietJMull; 
type  Zat_ttoeaaa  isaoooes  Zat; 
t^  SaaTuntJloeaae  Is  access  Baal  lint; 
tyiM  Itaaljiee'^aa  Isacoeea  teal; 

tyte  Degblajtraaieiew ^teoasa  Is  access  Daubla^^Praeisloa; 

ty|M  PQTJjnflilJareaarai  (SQZTZPS  iSQl^Dynael e_DataCypas;a|tot_8pa«iigtad) 

is  reMfd  "*  ”  “ 

case  aqt*j||i»  |e 

whan  tet  Spoei£lad  B> 
nufl;“ 

when  PyaaHisj3kar  a> 

Chac^alca  :  Chas_teeass; 
when  Pyaawicjiaeiaml  |  Oyaa»ie_lh»aric  a> 

Paeiwat_Talaa  :  Daeiaal_teoass; 

When  DyBawic_^Zat  »  ~ 

Zatjralsa  :  Zat_teeaaa; 

When  Draaraic^SMlUat  «•> 

tealliet^^alua  :  S«alliat_teaaaa; 
when  Dyeaedejlaal  ■>  ** 

teaX^alaa  :  teal_teeoss; 

When  nywawtc_J>oobla_Praclsiea  |  DyDaada!__rioat  ■> 

Deobla^Praeiaioa^alus  :  Doubla_Praexaien_Acoass; 
end  ease;  ”  “  "* 

end  record; 

type  SQ£Vaiijeoepeaoet_Typa  is  record 


:  SQL_I>yaaBia_t*raMt*r; 

SQUraUJUaJE  :*‘ZadiMtor_«3rp«; 

SQLZaD  t  XadleatocJCyp*; 

■«W1«»M»T.  ;  tea,  ColMH  Kaaajbaogfth  Tn**'* 
'  aguoMt  t  tau&ajtx^i 
•ntf  raeord; 


typa  tQIiVlUIJIXP* 

ainiy  (Znfe  rang*  o)  of  sai>v«r_co^o«i«at_Typ«; 


typ*  SQllMi  (SQU  s  Znt)  is  raeord 
MQU>  :  Znt; 

SOLVMl  »  Sflcmuijfspo  (1  •• 
•nd  raeord; 


•nd  SOL  tt«ad*sd_pyBaaia; 


I 


Package  SQLJ)ynancLc_Pkg 

««•  MOZ.JUmmJCyp^t  Pkg;  “ 

pwkag*  SQl.j)ya««i^Pkg  is 

~bSJr . 

««btyp, 

*yP*  ^Ot_Pyiiaaaej)«t«typ«a  !« 

Dyiuiiic_D«ei«*i, 

Py**— Oya*»io^SMllint, 

®^^****^®~***^>  ®y»»»ie_Ooubi«__P*«ei«loo)  • 

i3L*^***”“*  tjp**  la  a«,  tvB*  Pk. 

«yp«  ck«r_i«0M«  isaecMs  SQt  cawTr^J: 

0*o1»>l^Aec«—  isaecMs  SOL  O^ImI  iyp«- 
^P«  Zat^Aaoaaa  {aaeeaaa  Sfll.  tat^typa,*  ***^' 
taalline^Aceaaa  iaaccass  SQL  e..n^nt  Typ«. 
taal.Acoaaa  taaecaaa  SQt  *..1^^-^' 
tfp*  0«ibla_Ps.eiaioo_^.„  is  accats  SCt.Doubla_,Pr.«i.iea__T«,a; 

••*C^-.^c^0.t*typaa  :-  »ot  Spacit. 

CM#  SQZTypm  is 

Whan  Moejgpacittai  ■> 
auU;  ; 

Whan  Opnaale  rsfr  «> 

Char^VaX^  ;  Chair  Xeeaaa; 

Whan  OytMaiejDaeiMal  ■> 

iaha#t*1l!i**r-^"*  '  ^‘^"■•iJWtoaaa/ 

Whan  OyaaMie^Zat  ■> 

latJPalaJ"  :  Xat  Accmmm;  ' 

WtMn  DynsMio  *-- in7t  a> 

toanint'ValMa  ;  a-.tt4-^  - - 

Whan  Oyaa^jlMl  ■>  ■" 

^Saaljrali  ,•  «m1  aooaaa? 

wnan  OyaaMio_o«abXa  PrMialaa  •> 

and  •*  OonbU^Pwolala.  looaaa; 


Hoe^Spael£i.ad 


*  *®*!«.*^y®*w^®^ya»M»ata*; 

f  dQSi  ColiSMi  ICaaM  fwtLj. 

,v  aQuoMB  5  aezaMK 

•nd  raeord;  ~ 

<y(M  •osvujryp*  to 

•ray  (iot^iBtjiatjiBU  ranga  oj  of  agsva 

typa  aom  (agui  :  aBt_x.t  hm  a«ii,  i.  raeord 
doto  I  MQL  Zot  BoTauU-  “ 
aw  .  aoL^_,y5.  ,1  .. 


•««d  aotJBynaoieJPkg; 


Appendix  C.  Abstract  Interface  Domain  Primitive  Types  Code 


The  following  listing  provides  the  abstract  interface  code  for  the  Domain  Primitive 
Types  that  was  developed  and  discussed  in  Chapter  IV.  For  ease  of  understanding,  the 
information  is  organized  in  a  form  that  is  not  compilable.  To  clarify  how  each  attribute 
contributes  to  this  package,  each  attribute’s  information  is  consolidated  in  one  area  which 
is  separated  from  other  attribute  information  areas  by  a  blank  line.  To  implement  these 
packages  all  generic  “SQL_*.  Pkg.SQL_=*'_OPS(...)”  packages  must  be  moved  to  the  end 
of  each  entity  package  since  they  are  later  declarative  items.  Each  Primitive  Type 
Package  begins  on  a  new  page. 
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Package  The_Area_primitive_domain_types 


with  SQL_Int_Pk:g, 

SQL_Char_Pkg; 

package  The_Area_primitive_doinain_types  is 

type  AREA_ID_Not  Null  is  new 
SQL_Int_Pkg.S(fL_Int_Not_Null; 
type  AREA_ID_Type  is  new 
SQL_Int_Pkg,SQL_Int; 
package  AREA_ID_Ops  is  new 
SQL_Int_Pkg.SQL_Int_Ops 
(AREA_ID_Type,  AREA_ID_Not_NulI ); 

type  DOMAINNN_Base  is  new 

SQL_Char_Pkg.SQL_Char_Not_Null; 
subtype  DOMAIN  Not_NuIlis 
DOMAINNN  Base 
(1..256); 

type  DOMAIN_Base  is  new 
SQL_CharlPkg.SQL_Char; 
subtype  DOMAIN  Type  is 
DOMAIN  ^ase 
(DOMAIN_Not__Null'Length); 
package  DOMAIN_Ops  is  new 
SQL_Char_Pkg.SQL_Char_Ops 
(DOMAIN_Base,  DOMAIN_Not_Null ); 


typeSEANN  Base  is  new 

SQL_Cha7_Pkg.SQL_Char_Not_Null; 
subtype  SEA  Not_NuH  is 
SEANN_Base 
(1..256); 

type  SEA_Base  is  new 

SQL_Char_Pkg.SQL_Char, 
subtype  SEA_Type  is 

QC  A  Rocp 

(SEA_Not_Nuirixngth); 
package  SEA_Ops  is  new 

SQL_Char_Pkg.SQL_Char_Ops 
(SEA_Base,  SEA_Not_Null ); 
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type  PHASENN_Base  is  new 

SQL_Char_Pkg.SQL_Char_Not_Null; 
subtype  PHASE  Not_NulIis 
PHASENN  Base 


(L.256); 

type  PHASE_Base  is  new 
SQL_Char_Pkg,SQL_Char, 
subtype  PHASE_Type  is 
PHASE  Base 

(PHASE_Not_NuirLength); 


package  PHASE_Ops  is  new 
SQL_Char_Pkg.SQL_Char_Ops 
(PHASE_Base,  PHASE_Not_NulI ); 


end  The_Area_priniitive_domain_types; 
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Package  General_Software_Characteristic _primitive_domainjypes 


with  SQL_Int_Pkg, 

SQL_Char_Pkg, 

SQL_Enumeration_Pkg, 

package  General_Software_Characteristic_priniitive_domain_types  is 

type  GSC_K)_Not  Null  is  new 
SQLJnt_Pkg.SQLJnt_Not_Null; 
type  GSC_ID_Type  is  new 
SQL_Int_Pkg.SQL_Int; 
package  GSC_ID_Ops  is  new 
SQL_Int_Pkg.SQL_Int_Ops 
(GSCJD_Type,  GSC_ID_Not_Null ); 

type  CHARACT_NAMENN  Base  is  new 
SQL_Char_Pkg.SQL_Char_Not_Null; 
subtype  CHARACT.NAME  Not  NuU  is 
CHARACT_NAMENN  Base 
(1..256); 

type  CHARACT_NAME  Base  is  new 
SQL_Char_Pkg.SQLlChar, 
subtype  CHARACT_NAME_Type  is 
CHARACT_NAME_Base 
(CHARACT_NAME_Not_Null'Lcngth); 
package  CHARACT_NAME_Ops  is  new 
SQL_Char_Pkg.SQL_Char_Ops 

(CHARACT_NAME_Base,  CHARACT_NAME_Not_Null ); 

type  formu_?NN_Base  is  new 

SQL_Char_Pkg.SQL_Char_Not_Null; 
subtype  formu_?_Not_Null  is 
formu_?NN_Base 
(1..256); 
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type  formu_?_Base  is  new 
SQL_Char_Pkg.SQL_Char, 
subtype  formu_?_Type  is 
formu_?_Base 
(formu_?_Not_NiiirLength); 
package  formu_?_Ops  is  new 
SQL_Char_Pkg.SQL_Char_Ops 
(formu_?_Base,  formu_?_Not_NulI ); 

type  evalu_?NN_Base  is  new 

SQL_Char_Pkg.SQL_Char_Not_Null; 
subtype  evalu_?_Not_NuII  is 
evalu_?NN_Base 
(1..256); 

type  evalu_?_Base  is  new 
SQL_Char_Pkg.SQL_Char, 
subtype  evalu_?  Type  is 

evalu_?3as® 

(evalu_?_Not_NulI'Length); 
package  evalu_?_Ops  is  i.ew 
SQL_Char_Pkg.SQL_Char_Ops 
(evalu_?_Base,  evalu_?_Not_NuII ); 

type  evalu_helpNN  Base  is  new 

SQL_Char_Pkg.SQL_Char^Not_NulI; 
subtype  evalu_help  Not_NuII  is 
evalu  helpl^  Base 
(I. .256); 

type  evalu_help_Base  is  new 
SQL_Char_Pkg.SQL_Char, 
subtype  evalu_help_Type  is 
evalu_help_Base 
(cvalu_help_Not_NuirLcngth); 
package  evaIu_help_Ops  is  new 
SQL_Char_Pkg.SQL_Char_Ops 
(evalu_help_Base,  evaIu_help_Not_Null ); 

type  cssentiai_flag_Not_NulI  is  (Is_Falsc,  Isjruc); 
package  essential_flag_Pkg  is  new 
SQL_Enu  mcration_Pkg 
(c.sscntial_flag_Not_NuII); 
type  csscntial_flag  Type  is  new 

c.ssential_flag_Pkg.SQL_Enumcrati()n_Pkg; 

type  evalu_nicth(xl_Nol_Null  is  (Is_Falsc,  Isjruc); 
package  eva!u_nicih(xI_Pkg  is  new 
SQL_Enumcration_Pkg 
(cvalu_mcth(xl_Not_NuII); 
type  cvalu_mcth(xl_Type  is  new 

cvaIu_mcthod_Pkg.SQL_Enumcration_Pkg; 
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type  empirical_weight_Not_Nun  is  new 
SQL_Int_Pkg.SQL_InLNot_Null; 
type  etnpirical_weight_Type  is  new 
SQL_Int_Pkg.SQL_lnt; 
package  empirical_weight_Ops  is  new 
SQL_Int_Pkg.SQL_InrOps 
(en'.oirical_weight_Type,  empirical_wcight_Not_Null ); 

end  General_Software_Characteristic_primitive_domain_types; 
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Package  The  Tool _primitive_domain_types 


with  SQL_Int_Pkg, 

SQL_Char_Pkg, 

SQL_Decimal_Pkg; 

package  The_TooI_primitive_domain_types  is 

type  TOOLJD  Not_NuIl  is  new 
SQL_Int_Pkg.SQLJnt_Not_NuIl; 
type  TOOL_ID_Type  is  new 
SQL_Int_Pkg.SQL_Int; 
package  TOOL_ID_Ops  is  new 
SQL_Int_Pkg.SQL_Int_Ops 
(TOOL_ID_Type,  TOOL_ID_Not_NuU ); 

type  TOOL_NAMENN_Base  is  new 
SQL_Char_Pkg.SQL_Char_Not_Null; 
subtype  TOOL_NAME  Not  Null  is 
T00L_NAMENN  Base 
(1..256); 

type  TOOL_NAME  Base  is  new 
SQL_Char_Pkg:SQL_Char, 
subtype  TOOL.NAME  Type  is 
TOOL.NAMEjBase 
(TOOL_NAME_Not_NuU'Length); 
package  TOOL_NAME_Ops  is  new 
SQL_Char_Pkg.SQL_Char_Ops 
(TOOL_NAME_Base,  TOOL_NAME_Not_Null ); 

version_scale:  constant  decimal_cligits:=  2; 
type  VERSIONNN_Base  is  new 

SQL_Dec  imal_Pkg.S  QL_Deci  mal_Not_N  u  1 1 ; 
subtype  VERS10N_Not_Null  is 
VERSIONNN_Base 
(scale  =>  version_scalc); 
type  VERS10N_Base  is  new 

SQL_Decirnal_Pkg.SQL_Decimal; 
subtype  VERSION_Type  is 
VERSION_Base 
(scale  =>  version_scale); 
package  VERSION_Ops  is  new 

SQL_Decimal_Pkg.SQL_Decimal_Ops 

(VERSION_Base, 

VERSIONNN_Base, 
in_scale  =>  version_scale); 
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type  vendorNN_Base  is  new 

SQL_Char_Pkg.SQL  _Char_Not_Null; 
subtype  vendor__Not_Null  is 
vendorrTN  Base 


(1..256); 

type  vendor_Base  is  new 

SQL_Char_Pkg.SQL_Char, 
subtype  vendor_Type  is 
vendor  ^ase 


(vendor_Not_NuirLength); 
package  vendor_Ops  is  new 

SQL_Char_Pkg.SQL_Char_Ops 
(vendor_Base,  vendor_Not_Null ); 


cost_scale:  constant  decimal_digits:=  2; 
type  costNN_Base  is  new 

SQL_DecimaLPkg.SQL_Decinial_Not_Null; 
subtype  cost_Not_Null  is 
costNN_Base 
(scale  =>  cost_scale); 
type  cost_Base  is  new 

SQLrDecimal_Pkg.SQL_Decimal; 
subtype  cost_Type  is 
cost  Base 

(scale  =>  cosLscale); 
package  cost_Ops  is  new 

SQL_DecimaLPkg.SQL_Decinial_Ops 

(cost_Base, 

costNN_Base, 

in_scale  =>  cost_scaIe); 


end  The_Tool_primitive_domain_types; 
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Package  TheJEvaluator primitive jlomainjypes 


with  SQL_Int_Pkg, 

SQL_Char_Pkg, 

SQL_Date_Pkg; 

package  The_Evaluator_primitive_domain_types  is 


type  EVAL_ID_Not_NuH  is  new 
SQL_Int_Pkg.SQL_Int_Not_Null; 
type  EVAL_ID_Type  is  new 
SQL_Int_Pkg.SQL_Int; 
package  EVAL_ID_Ops  is  new 
SQL_Int_Pkg.SQL_Int_Ops 
(EVAL_ID_Type,  EVAL_ID_Not_NuU ); 


type  FIRST_NAMENN_Base  is  new 
SQL_Char_Pkg.SQL_Char_Not_Null; 
subtype  FIRST_NAME_Not_NuU  is 
FIRST_NAMENN  Base 
(1..256); 

type  FIRST  NAME  Base  is  new 
SQL  Char_Pkg:SQL_Char; 
subtype  FIRST_NAME  Type  is 
FIRST  NAME  Base 


(FIRST_NAME_Not_NuH'Length); 
package  FIRST_NAME_Ops  is  new 
SQL_Char  Pkg.SQL_Char_Ops 
(FIRST_NAME_Base,  FIRST_NAME_Not_Nun ); 


type  LAST_NAMENN_Base  is  new 
SQL_Char_Pkg.SQL_Char_Not_Null; 
subtype  LAST_NAME_Not_NuU  is 
LAST  NAMENN  Base 


(1..256); 

type  LAST_NAME_Base  is  new 
SQL_Char_Pkg.SQL_Char; 
subtype  LAST_NAME  Type  is 
LAST_NAME  "Base 


(LAST_NAME_Not_Null'Lcngth); 
package  LAST_NAME_Ops  is  new 
SQL_Char_Pkg.SQL_Char_Ops 
(LAST_NAME_Base,  LAST_NAME_Not_Null ); 
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type  dateNN_Base  is  new 

SQL_Date_Pkg.SQL_Datc_Not_Null; 
subtype  date_Not_NuU  is 
dater5N_Base  (1..10); 
type  date_Base  is  new 

SQL_Datc_Plvg.S  QL_Datc 
(From  =>year,  To=>Day,  Fractional  =>0); 
package  date_Ops  is  new 

SQL_Date_Pkg.SQL_Date_Ops 
(date_Type,  dateNNBase); 

type  typeNN_Base  is  new 

SQL_Char_Pkg.SQL_Char_Not_Null; 
subtype  type  Not_Null  is 
typeSrN_Base 
(1..256); 

type  type_Base  is  new 

SQL_Char_Pkg.SQL_Char, 
subtype  type_Type  is 
type_Base 

(type_Not_Null'Length); 
package  tyi^  Ops  is  new 

SQL_Ch^r_Pkg.SQL_Char_Ops 
(type_Base,  type_Not_NuIl ); 

end  The_Evaluator_,primitive_domain_types; 
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Package  The_Quality _primitive_domain_types 


with  SQL_Int_Pkg, 

SQL_Char_Pkg; 

package  The_QuaIity_priniitive_domain_types  is 

type  QUALJD  Not_Null  is  new 
SQLJnt_Pkg.SQL_Int_Not_Null; 
type  QUAL_ID_Type  is  new 
SQL_Int_Pkg.SQL_Int; 
package  QUAL_ID_Ops  is  new 
SQL_Int_Pkg.SQL_Int_Ops 
(QUALJD_Type,  QUAL_ID_Not_Null ); 

type  QUALITY_NAMENN_Base  is  new 
SQL_Char_Pkg.SQL_Char_Not_Null; 
subtype  QUALITY  NAME_Not_Nuli  is 
QUALITYJnAMENN  Base 
(1..256); 

type  QUALITY_NAME  Base  is  new 
SQL_Char_Pkg.SQC  Char, 
subtype  QUALITY.NAME  Type  is 
QUALITY  NAME  Base 
(QUALITY_NAME_Not_Nun'Length); 
package  QUALITY_NAME_Ops  is  new 
SQL_Char_Pkg.SQL_Char_Ops 

(QUALITY_NAME_Base,  QUALITY_NAME_Not_Null ); 

type  QUALITY_VALUENN_Base  is  new 
SQL_Char_Pkg.SQL_Char_Not_Null; 
subtype  QUALITY_VALUE_Not_NulI  is 
QUALITY.VALUENN  Base 
(L.256); 

type  QUALITY_VALUE_Base  is  new 
SQL_Char_Pkg.SQL_Char, 
subtype  QUALITY.VALUE  Type  is 
QUALITY_VALUE_Base 
(QUALlTY_VALUE_Not_Null'Lcngth): 
package  QUALITY_VALUE_Ops  is  new 
SQL_Char_Pkg.SQL_Char_Ops 

(QUALITY_VALUE_Base,  QUALITY_VALUE_Not_Null ); 
end  The_Quality_primitive_domain_types; 
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Package  The_Specific_Software_Characteristic j)rimitive_domainjypes 


with  SQL_Int_Pkg, 

SQL_Char_Pkg; 

package  The_Specific_Software_Characteristic_primitive_domain_types  is 

type  SSC_ID_Not_NuIl  is  new 
SQL_Int_Pkg.SQL_Int_Not_Null; 
type  SSC_ID_Type  is  new 
SQL_Int_Pkg.SQL_Int; 
package  SSC_ID_Ops  is  new 
SQL_Int_Pkg.SQL_Int_Ops 
(SSC_ID_Type,  SSC_ID_Not_NuII ); 

type  valueNN_Base  is  new 

SQL_Char_Pkg.SQL_Char_Not_Null; 
subtype  value_Not_NuIl  is 
valueNN  Base 
(L.256)r 

type  value  Base  is  new 

SQL_Char_Pkg.SQL_Char, 
subtype  value_Type  is 
value_Base 

(value^Not_Null'Length); 
package  value_Ops  is  new 

SQL_Char_Pkg.SQL_Char_Ops 
(value_Base,  value_Not_Null ); 


type  tepNN_Base  is  new 

SQL_Char_Pkg.SQL_Char_Not_Null; 
subtype  tep_Not_Null  is 
tepNN  Base 
(1..2561; 

type  tep_Base  is  new 

SQL_Char_Pkg.SQL_Char, 
subtype  tep_Type  is 
tep_Base 

(tep_Not_Nu!rLength); 
package  tep_Ops  is  new 

SQL_Char_Pkg.SQL_Char_Ops 
(tep_Base,  tep_Not_NuII ); 


endThe_Specific_Software_Characieristic_primiiivc_cloniain_typcs; 
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Package  WeightJSet _primitive_domain_types 


with  SQL_Char_Pkg, 

SQL_Enumeration_Pkg; 
package  Weight_Set_primitive_domain_types  is 

type  WEIGHT_SET_NAMENN_Base  is  new 
SQL_Char_Pkg.SQL_Char_Not_Null; 
subtype  WEIGHT_SET_NAME_Not_NuIl  is 
WEIGHT_SET_NAMENN_Base 
(1..256); 

type  WEIGHT_SET_NAME_Base  is  new 
SQL_Char_Pkg.SQL_Char, 
subtype  WEIGHT_SET_NAME_Type  is 
WEIGHT_SET_NAME_Base 
(WEIGHT_SET_NAME_Not_NuirLength); 
package  WEIGHT_SET_NAME_Ops  is  new 
SQL  Char_Pkg.SQL  Char_Ops 

(WErGHT_SET_NAME_Base,  WEIGHT_SET_NAME_Not_NuH ); 

type  ciefault_Not  Null  is  (Is_False,  Isjrue); 
package  defaultJPkg  is  new 
SQL_Enumeration_Pkg 
(default_Not_Null); 
type  default_Ty^  is  new 

default_Pkg.SQL_Enumeration_Pkg; 

end  Weight_Set_primitive_domain_types; 
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Package  Selection_Set j)rimitive_domainjypes 


with  SQL_Char_Pkg; 

package  Selection_Set_priniitive_(iomain_types  is 

type  SET_NAMENN_Base  is  new 

SQL_Char_Pkg.SQL_Char_Not_Null; 
subtype  SET_NAME_Not_NulI  is 
SET_NAMENN  Base 
(1..256); 

type  SET_NAME_Base  is  new 
SQL_Char_Pkg.SQL_Char, 
subtype  SET_NAME_Type  is 
SET_NAME_Base 
(SET_NAME_Not_NulI'Length); 

package  SET_NAME_Ops  is  new 
SQL_Char_Pkg.SQL_Char_Ops 
(SET_NAME_Base,  SET_NAME_Not_NuII ); 

end  SeIection_Set_priniitive_domain_types; 
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Package  software _c1iar_score primitive _domainjypes 


with  SQL_Decitnal_Pkg; 

package  software_char_score_primitive_(iomain_types  is 

software_char_function_score_scale:  constant  decinial_digits:=  2; 
type  software_char_function_scoreNN_Base  is  new 
SQL_Decinial_Pkg.SQL_DecimaI_Not_Null; 
subtype  software_char_function_score_Not_Null  is 
software_char_function_scoreNN_Base 
(scale  =>  software_char_function_score_scale); 
type  software_char_function_score_Base  is  new 
SQL_Decimal_Pkg.SQL_Decimal; 
subtype  software_char_function_score_Type  is 
software_char_function_score_Base 
(scale  =>  software_char_function_score_scale); 
package  software_char_function_score_Ops  is  new 
SQL_Decimal_Pkg.SQL_Decimal_Ops 
(software_char_function_score_Base, 
software_char_function_scoreNN_Base, 
in_scale  =>  software_char_function_score_scale); 

software_char_quality_score_scale:  constant  decimal_digits:>=  2; 
type  software_char_quality_scoreNN_Base  is  new 
SQL_Decimal_Pkg.SQL_Deci  maT_Not_Null ; 
subtype  software_char_quality_score_Not_NuU  is 
software_char_qualiiy_scorcNN_Base 
(scale  =>  software_char_quality_score_scale); 
type  software_char_quality_score_Base  is  new 
SQL_Decinial_Pkg.SQL_Decimal; 
subtype  software_char_quality_score_Type  is 
software_char_quality_score_Base 
(scale  ==>  software  _char_quality_score_scale); 
package  software_char_quality_score_Ops  is  new 
SQL_Decinial_Pkg.SQL_Deciniat_Ops 
(software_char_quality_scorc_Base, 
softwarc_char_quality_scoreNN_Base, 
in_scale  =>  software_char_quality_scorc_scalc); 
end  software_char_score_primitive_domain_typcs; 
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Package  tool_score _primitive_domain_types 


witli  SQL_Decimal_Plcg; 

package  tool_score_primitive_domain_types  is 

tooI_function_score_scaIe:  constant  decimal_digits:=  2 
type  tool_function_scoreNN_Base  is  new 

SQL_Decimal_Pkg.SQL_Decimal_Not_Null; 
subtype  tool_function_score_Not_NuIl  is 
tool_function_scoreNN_Base 
(scale  =>  tool_function_score_scale); 
type  tool_function_score_Base  is  new 
SQL_Decinial_Pkg,SQL_Decimal; 
subtype  tooLfunction_score_Type  is 
tooI_function_score_Base 
(scale  =>  tool_function_score_scale); 
package  tooLfunction_score_Ops  is  new 
SQL_Decimal_Pkg.SQL_Decinial_Ops 
(tooLfunction_score_Base, 
tooi_function_scoreNN_Base, 
in_scale  =>  tool_function_score_scale); 

tooLquality_score_scale:  constant  decimal_digits:=  2; 
type  tool_quality_scoreNN  Base  is  new 

SQL_DecimaLPkg.SQL_DecimaLNot_Null; 
subtype  tool_quality_score_Not_Null  is 
tool_quality_scorcNN_Base 
(scale  =>  tool_quality_scorc_scale); 
type  tool_quality_scorc_Ba3e  is  new 
SQL_Dccimal_Pkg.SQL_Dccimal; 
subtype  tooLquality_score_Type  is 
tooLquality_score_Base 
(scale  =>  tool_quality_scorc_scale); 
package  tool_quality_score_Ops  is  new 
SQL_Dccimal_Pkg.SQL_Decimal_Ops 
(tooLqual  ity_score_Base, 
tooLquality_scoreNN_Base, 
in_scale  =>  tooLqual  ity_score_scale); 


end  tool_scorc_primitivc_doniain_typcs; 


Package  software _char_weight _primitive_domainjypes 


with  SQL_Int_Pkg; 

package  software_char_weight_primitive_doinain_types  is 

type  function_weight_Not  Null  is  new 
SQL_Int_Pkg.SQL_IntlNot_Null; 
type  function_weight_Type  is  new 
SQL_Int_Pkg.SQL_Int; 
package  function_weight_Ops  is  new 
SQL_Int_Pkg,SQL_Int_Ops 
(function_weight_Type,  function_weight_Not_NulI ); 

type  quality_weight_Not_NuU  is  new 
SQL_Int_Pkg.SQLJnt_Not_Null; 
type  quality_weight_Type  is  new 
SQL_Int_Pkg.SQL_Int; 
package  quality_weight_Ops  is  new 
SQL_Int_Pkg.SQL_Int_Ops 
(quality_weight_Type,  quality_weight_Not_NuH ); 

end  software_char_weight_primitive_domain_types; 
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Appendix  D.  Abstract  Interface  Composite  Methods  Code 


The  following  listing  provides  the  abstract  interface  composite  methods  code  that 
was  developed  and  discussed  in  Chapter  IV.  The  code  in  this  appendix  is  compilable  as 
long  as  the  SAME  packages  have  already  been  installed  on  the  users  system.  The  code 
defines  the  abstract  interface  by  providing  the  specifications  to  that  interface,  the  bodies 
to  these  specifications  can  be  implemented  using  the  behavioral  description  provided  in 
Chapter  IV  as  a  guideline.  These  packages  represent  the  second  piece  to  the  logical  entity 
descriptions  defined  in  Chapter  IV.  Recall  that  a  logical  entity  represented  both  the 
domain  primitive  type  and  the  methods  that  operated  on  that  type.  The  domain  primitive 
types  are  presented  in  Appendix  C,  the  methods  that  operate  on  those  types  are  presented 
here. 

Simplifying  assumptions  were: 

•  A  Formulator  released  SAI  structure  would  not  be  altered  after  an  evaluator  or 
selector  process  used  that  structure.  The  final  .system  will  have  to  insert  abstract  interface 
code  that  would  support  this  type  of  system  requirement. 

•  Dynamic  SQL  statements  require  a  package  shell  which  contained  a  dc.scription  of 
the  parameters  that  are  dynamic.  This  package  is  required  for  acce.ssing  Thc_Area, 
software_char_score,  The_T(X)l,  Specific  Software  Characteristic,  and  Thc_Quality 
combined  attributes.  This  package  operates  across  several  domain  primitive  types  to 
accomplish  the  STEMdB  requirement  that  the  tool  selection  process  allow  the  user  to 
constrain  anywhere  from  one  to  several  of  the  attributes  located  in  thc.se  domains. 
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Package  Tooljiarrowing 


with  SQL_Base_Types_Pkg, 

SQL_Dynamic_Pkg 

The_Area_primitive_domain_types, 

software_char_scoie_primitive_domain_types, 

'nie_T(X)l_prjmitive_domain_types, 

Specific  Software  Characteristic_priinitivc_domain_typcs, 

'liie_Quality_primitivc_doniain_typcs, 

The_Evaluator_primitive_domain_types; 

use  SQL_Base_Types_Pkg, 

SQL_Dynamic_Pkg 

The_Area_primitive_domain_types, 

software_char_score_primitive_domain_types, 

The_Tool_primitive_doniain_types, 

Specific  Sofware  Characteristic_primitivc_domain_types, 

The_Quality_primitive_domain_types, 

The_Evaluator_primitive_domain_types; 

Package  Tool_narrowing  is 

Prepare(STMT:  SQL_Char_not_null); 

Allocate(for_SQLDA_name:  SQL_Char_not_nulI; 

Max:  SQL_int_not_null ); 

Describe_Input(for_SQLDAJn_area:  SQL_Char_noi_nuII); 

Describe_output(for_SQLDA_out_arca:  SQL_Char_not_null); 

Get_Number_paramcicrs(for_givcn_SQLDA:  SQL_Char_not_null; 

num:  out  SQL_Int_not_null); 

Get_parameter_typc(paramctcr_nuinber:  SQL_Int_not_null; 

for_givcn_SQLDA;  SQL_Char_not_nuIl; 
paramctcr_typc:  out  SQL_Dynamic_Data_typcs): 

Sct_paramctcr_valuc(paranictcr_numbcr:  SQL_lni_noi_null; 

for_givcn_SQLDA:  SQL_Char_not_null; 
SQLDATA:  in  SQL_Char_typc); 

Get_paramcter_valuc(paramctcr_numbcr:  SQL_Ini_noi_null; 

from_givcn_SQLDA:  SQL_Char_not_null; 
SQLDATA:  out  SQL_Char_iypc); 

Opcn_Cursor(for_SQLDA_namc:  SQL_Char_noi_null): 

Fctch(placc_in_SQLDA_namc:  out  SQL_Char_not_null: 
valuc_fetchcd:  out  Ixxilcan); 
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Close_cursor; 
end  TooLnaiTowing; 


Package  Database  ^Transactions 


Package  Database_Transactions  is 
-Required  initialization  routine 
Procedure  CreateTables; 
-Transactions 

Procedure  Commit; 
Proceudure  Rollback; 
end  Database_Transactions; 


Package  The_Area_Composite_OPS 


with  SQL_Base_Types_Pkg, 

The_Area_primitive_domain_types; 


use  SQL_Base_Types_Pkg, 

The_Area_primitive_domain_type; 


Package  The_Area_Composite_OPS  is 

Type  area_rccoKl_type  is  record 

AREA_ID:  AREA_ID_Not_Null; 

DOMAIN:  DOMAlN_Not_Null; 

SEA:  SEA_Not_Null, 

PHASE:  PHASE_Not_Null; 

end  record; 

-insert  operation 

Procedure  insert_domain_sea_phase(area_record:  area_record_type); 

-all  gouped  inserts  must  have  non-null  fields  in  a  record  so  abstract  interface  operates 

-on  them  as  a  record. 

-update  operations 

Procedure  update_Arca(area_record:  area_record_type; 

with_this_AREA_ID:  AREA_ID_Not_Null; 
not_found:  out  boolean); 

Procedure  update_Domain(area_rccord:  area_record_type; 

vvith_thi s_Domain :  DOM AlN_Not_N nil; 
not_found’  out  boolean); 

Procedure  update_SEA(area_record:  area_record_typc; 

with_this_SEA:  SEA_Not_Null; 
not_found:  out  boolean); 
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Procedure  update_Phase(area_record:  area_record_type; 

with_this_Phase:  PHASE_Not_Null; 
not_found:  out  boolean); 


-search  operation 

Function  search_domainseaphase(area_record:  area_record_type)  return  boolean; 
-delete  operation 

Procedure  delete_domain_sea_phase(area_record:  area_record_type; 

deleted:  out  boolean); 

-retrieve  operation 

Function  UniquelD  return  AREA_ID_Not_Null; 


Procedure  get_area_record(for_area;  AREA_ID_Not_Null; 

area_record:  in  out  area_rccord_typc; 
exists:  out  boolean); 


end  The_Area_Coniposite_OPS; 
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Package  root  node jOompositejOPS 


with  SQL_Base_Types_Pkg, 

The_Area_primitivejdomain_types, 

General_Software_Qiaracteristic_primitive_domain_types; 

use  SQL_Base_Types_Pkg, 

The_Area_primitive_domain_types, 

General_Software_Characteristic_primitive_domain_types; 

Package  root_node_Composite_OPS  is 

Type  root_node_recoKl_type  is  record 
AREAJD:  AREAJD_Not_Null; 

GSC;  GSC_ID_Not.  Null; 
end  record; 


--insert  operations 
-implemented  by  insert  values 

Procedure  insert_GCS_id_Area_id(root_node:  root_node_record_type); 

-update  operations 
-implemented  by  searched  update 

Procedure  update  Aiea(this  root_node:  in  root_node_record  type; 

with_this_AREA_ID:  AREA_ID_Not_Null; 
not_found:  out  boolean); 

Procedure  update_GSC(this_root_node;  in  root_nodc_record_type; 

with_this_GSCjn:  GSCJD_Not_Null; 
not_found;  out  boolean); 


-search  operation 

-implemented  by  select, fetch,  check 

Function  search_GCS_id_Area_id(r(X)t_nodc:  root_nodc_rccord_typc) 

return  b(X)lcan; 
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--delete  operations 
-implemented  by  searched  delete 

Procedure  delete_GCS_id_Area_id(root_node:  root_node_record_type; 

is_deleted:  boolean); 

-retrieve  operations 
-implemented  by  cursor/select 

Package  get_gsc_for_area  is 

Procedure  Open(for_this_AREA_ID:  AREA_ID_Not_Null) 

Procedure  Fetch(this_GSC_ID_record:  in  out  root_node_record_type, 
is_fetched:  boolean) 

Procedure  close; 
end  get_gsc_for_area ; 

Package  get_area_for _gsc  is 

Procedure  Open(for_this_GSC_ID:  GSC_ID_Not_Null) 

Procedure  Fetch(this_AREA_ID_record;  in  out  root_node_record_type, 
is_fetched:  boolean) 

Procedure  close; 
end  get_area_for_gsc ; 

end  root_node_Composite_OPS; 
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Package  General _Software_Characteristic_Composite_OPS 


with  SQL_Base_Types_Pkg, 

GeneraLSoftware_Characteristic_primitive_domain_types, 

The_Area_priniitive_domain_types; 

use  SQL_Base_Types_Pkg, 

General_Software_Characteristic_primitive_domain_types, 
The_Area_primitiv  c_doniain_types; 

Package  General_Software_Characttristic_Composite_OPS  is 

Type  GSC_record  type  is  record 
GSC:  GSCJD_Not_Null; 
CHARACT_NAME_Not_Null; 
formu_?_Type; 
evalu_?_Not_NulI; 
evalu_help_Type; 
essential_flag_Type; 
evalu_method_Type; 
empirical_weight_Type; 
end  record; 


--insert  operations 

Procedure  insert_gsc_record(GSC_record:  GSC_record_type); 

-update  operations 

-The  null  value  is  allowed  to  be  input  for  all  non-key  attributes  except  evaluation 
-question  since  this  question  is  mandatory  for  the  Evaluator  subsytem  to  prompt  the 
-user  for  input 

-Implemented  by  searched  update 

Procedure  updatc_gsc_id(for_given_GSC:  GSC_ID_Not_Null; 

GSC_ID:  GSC_lD_Not_Null; 
not_found:  out  b(X)lcan); 
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Procedure  update_gsc_name(for_given_GSC:  GSC_ID_Not_NulI; 

name;  CHARACT_NAME_Not_Null; 
not_found:  out  boolean); 

Procedure  update_formulation_comment(for_given_GSC:  GSC_ID_Not_Null; 

comment:  formu_?_Type; 
not_found:  out  boolean); 

Procedure  update_evaluation_question(for_given_GSC:  GSC_ID_Not_Null; 

question:  eval_?_Not_Null; 
not_found:  out  boolean); 

Procedure  update_evaluation_help(for_given_GSC:  GSC_ID_Not_Null; 

eval_help;  evalu_help_Type; 
not_found:  out  boolean); 

Procedure  update_essential_flag(for_given_GSC:  GSC_ID_Not_Null; 

essential:  essential_flag _ ^Type; 

not_found:  out  boolean); 

Procedure  update_evaluation_method(for_given_GSC:  GSC_ID_Not_Null; 

eval_method:  evalu_method_Type; 
not_found;  out  boolean); 

Procedure  update_empirical_weight(for_given_GSC:  GSC_ID_Not_Null; 

weight:  empirical_weight_Type; 
not_found:  out  boolean); 


-search  operations 
-delete  operations 

“  all  database  delete  operations  work  on  row  records.  To  delete  elements  in  a  row 
“the  update  operation  can  be  used  with  a  null  value. 

Procedure  delcte_gsc_record(for_given_GSC:  GSC_ID_Not_Null; 

is_deleted:  out  b(X)lean); 

-retrieve  operations 

Function  UniquelD  return  GSC_ID_Not_Null; 

Procedure  gct_GSC_rccord_for_GSC  (for_given_GSC:  GSC_lD_Not_Null; 

GSC_record:  in  out  GSC_record_typc, 
exists:  boolean); 


162 


Package  get_GSC_recor(I_for_Area  is 

Procedure  Open(for_given_Area:  Area_ID_Not_Null) 
Procedure  Fetch(GSC_record:  in  out  GSC_record_type, 
is_fetched;  boolean) 

Procedure  close; 
endget_GSC_record_for_Area; 

end  General_Software_Characteristic_Coniposite_OPS; 
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Package  LinkGG _Composite_OPS 


with  SQL_Base_Types_Pkg, 

General_Software_Characteristic_primitive_domain_typcs, 

The_Area_primitive_domain_types; 

use  SQL_Base_Types_Pkg, 

General_Software_Characteristic_primitive_domain_types, 

The_Area_primitive_domain_types; 

Package  LinkGG_Composite_OPS  is 

Type  linkGG_record_type  is  record 
parent:  GSC_ID_Not_Null; 
child:  GSC_ID_Type; 
end  record; 

-insert  operations 

Procedure  insert_linkGG_record(linkGG_record:  in  out  linkGG_record_type); 
-Can’t  have  a  child  without  a  parent  but  can  have  a  parent  that  is  childless 
Procedure  insen_child_gsc(given_record:  in  out  linkGG_record_type; 

inscn_child:  GSC_ID_Not_Null); 


-update  operations 

Procedure  update_parent_gsc(given_record:  in  out  linkGG_record_type; 

update_parent:  GSC_ID_Not_Null; 
not_found:  out  boolean); 

Procedure  update_child_gsc(given_record:  in  out  linkGGjccordjypc; 

update_child:  GSC_lD_Typc; 
not_found:  out  b(X)lcan); 


-search  operations 

Procedure  search_child_gsc(given_record:  in  out  linkGG_rccord_type; 

exists:  out  b(X)lean); 
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-delete  operations 

Procedure  delete_link(given_record;  linkGG_record_type; 

is_deleted:  out  boolean); 

-retrieve 

Procedure  get_Parent_Of(for_area;  AREA_ID_Not_Null; 

for_child;  GSC_ID_Not_Null; 
the_parent_record:  in  out  linkGG_rccord_type); 

Package  Get_children  is 

Procedure  Open(parent;  GSC_ID_Not_Null; 

Area_ID:  Area_lD_Not_Null); 

Procedure  Fetch(record_of_child:  in  out  linkGG_record_type, 
is_fetched:  out  boolean); 

Procedure  close; 
end  Get_children; 

end  LinkGG_Composite_OPS; 
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Package  The_Tool_Composite_OPS 


with  SQL_Base_Types_Pkg, 

The_Tool_primitive_(lomain_types; 

use  SQL_Base_Types_Pkg, 

The_TooLprimitive_doniain_typcs; 

Package  The_Tool_Composite_OPS  is 

Type  Tool_record_type  is  record 

TOOLJD:  TOOL_ID_Not_Null; 

TOOL_NAME:  TOOL_NAME_Not_NulI; 

VERSION:  VERSION_Not_Null; 
vendor:  vendor_Type; 
cost:  cost_Typc 

end  record; 

-insert  operations 
-implemented  by  insert  values 

Procedure  insert_tool_record(tool_record:  Tool_record_type ); 

-update  operations 
-implemented  by  searched  update 

Procedure  updatc_ToolJD(for_this_TOOLJD:TOOL_ID_NoLNull; 

with_this_Tool_ld:  TOOL_ID_Not_Null; 
not_found:  out  boolean); 

Procedure  updatc_ToolName(for_this_TOOL_lD;TOOL_lD_Not_Null; 

with_this_ToolName:  TOOL_NAME_Not_Null; 
notjound:  out  boolean); 

Procedure  updatc_Version(for_this_TOOL_ID:TOOL_ID_Noi_NuIl; 

with_this_Vcrsion:  VERS10N_Not_Null; 
not_found:  out  boolean); 

Procedure  updatc_vcndor(for_this_TOOL_ID:TOOL_ID_Not_Null; 

wiih_this_vcndor:  vcndor_Typc ; 
not_tound:  out  boolean); 

Procedure  update_cosi(for_this_TOOL_ID;TOOL_ID_Not_Null; 

with_ihis_cosi:  cost_Type  ; 
noi_found:  out  b(X)lean); 


-search  operation 

-implemented  by  select, fetch,  check 

Function  scarch_tool_rccord(t(X)l_rccord:  Tool_rccord_typc) 

return  boolean; 


-delete  operations 
-implemented  by  searched  delete 
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Procedure  delete_tool_record(for_this_TOOL_ID:TOOL_ID_Not_Null; 

is_deleted:  out  boolean); 

-retrieve  operations 

Function  UniquelD  return  TOOL_ID_Not_Null; 

-implemented  by  cursor/select 

Procedure  Tool_record_for_ID(for_this_TOOL_ID:TOOL_ID_Not_Null; 

this_Tool_record;  in  out  T{X)l_record_type, 
exists:  out  boolean) 


end  The_Tool_Composite_OPS; 
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Package  linkAT  CompositejOPS 


with  SQL_Base_Types_Pkg, 

The_Tool_primitive_domain_types, 

The_Area_primitive_doniain_types; 

with  SQL_Base_Types_Pkg, 

The_Tool_priniitive_domain_types, 

The_Area_primitive_domain_types; 

Package  linkAT_Composite_OPS  is 

Type  linkAT_record_type  is  record 

AREAJD:  AREAJD.Not.NulI; 
TOOLJD:  TOOL_ID_Not_Null; 
end  record; 


-insert  operations 
-implemented  by  insert  values 

Procedure  inscrt_LinkAT_record(linkAT_record:  linkAT_record_type ); 

-update  operations 
-implemented  by  searched  update 

Procedure  update_Arca(linkAT_record:  linkAT_record_typc ; 

with_this_AREA_ID:  AREA_1D_NolNu1I; 
not_found:  out  boolean); 

Procedure  updatc_Tool(Tool_ID:  TOOL_ID_Not_Null; 

with_this_TOOLJD;TOOLJD_Not_Null; 
not_found;  out  boolean); 


-search  operation 

-implemented  by  sclect,fctch,  check 

Function  scarchJinkAT_rccord(linkAT_rccord;  linkAT_rccord_typc ) 

return  b(X)lean; 
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--delete  operations 
-implemented  by  searched  delete 

Procedure  delere_linkAT_record(linkAT_rccord;  linkAT_rccord_type; 

is.  deleted:  out  boolean); 

-retrieve  operations 
-implemented  by  cursor/sclect 

Package  get_tools_for_area  is 

Procedure  Open(for_this_AREA_ID:  AREA_ID_Not_Null) 
Procedure  Fetch(this_TOOL_ID_record:  in  out  liiikAT_rccord_typc, 
is_fetched:  out  boolean) 

Procedure  close; 
end  get_tools_for_area ; 

Package  get_areas_for_tool  is 

Procedure  Open(for_this_TOOL_ID:  TOOI  _lD_Not_Null) 
Procedure  Feich(th'  .AREA_ID_record:  in  out  linkAT_record_typc, 
is_fctched:  out  boolean) 

Procedure  close; 
end  get_areas_for_tool ; 

end  linkAT_Composite_OPS; 
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Package  The_Evaluator_Composite_OPS 


with  SQL_Base_Types_Pkg, 

The_Evaluator_primitive_domain_types; 

use  SQL_Base_Types_Pkg, 

The_Evaluator_primitive_domain_types; 

Package  The_Evaluator_Composite_OPS  is 

Type  Evaluator_record_type  is  record 
EVAL_ID:  EVAL_ID_Not_Null; 

FIRST  NAME:  FIRST_NAME_Not_Null; 

LAST_NAME:  LAST_NAME_Not_Null; 
date:  date_Type; 
type:  type_Type 

end  record; 

-insert  operations 
-implemented  by  insert  values 

Procedure  inse’t_Evaluator_record(Evaluator_record:  Evaluator_rccord_type ); 

-update  operations 
-implemented  by  searched  update 

Procedure  update_EVAL_ID(for_this_EVAL_ID:EVAL_ID_Not_Null; 

with_this_Evaluator_Id:  EVAL_ID_NoLNull; 
not_found:  out  boolean); 

Procedure  update_FlRST_NAME(for_this_EVALJD:EVAL_ID_Not_Null; 

with_this_First_Name:  FIRST_NAME_Not_Null; 
notjbund:  out  boolean); 

Procedure  updatc_LAST_NAME(for_this_EV  AL_ID:EV  AL_lD_Not_Null; 

with_this_LAST_NAME:  LAST_NAME_Not_Null; 
not_found:  out  boolean); 

Procedure  updatc_date(for_this_EVAL_ID:EVAL_ID_Not_Null; 

with_this_date:  datc_Type ; 
notjbund:  out  boolean); 

Proccdu  re  updatc_ty  pc(for jh  is_E  V  AL_1D:  EV  AL_lD_Not_N  u  1 1 ; 

withjhisjypc:  typc_Type  ; 
notjbund:  out  boolean); 


-search  operation 

-implemented  by  select, fetch,  check 

Function  search_Evaluator_rccord(Evaluator_rccord:  Evaluator_rccord_typc) 

return  boolean; 


-delete  operations 
-implemented  by  searched  delete 
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Procedure  delete_Evaluator_record(for_this_EVAL_ID:EVAL_ID_Not_NuIl; 

is_deleted:  out  boolean); 

-retrieve  operations 

Function  UniquelD  return  EVAL_ID_Not_Null; 

-implemented  by  cursor/select 

Procedure  Evaluator_record_for_ID(for_this_EVAL_ID:EVAL_ID_Not_Null; 

th  is_Evaluator_record: 
in  out  Evaluator_record_type, 
exists:  out  boolean) 

end  The_Evaluator_Composite_OPS; 
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Package  linkESjOompositejOPS 


with  SQL_Base_Types_Pkg, 

The_Evaluator_primitive_domain_types, 

The_Specific_Software_Characteristic_primitive_domain_types; 


use  SQL_Base_Types_Pkg, 

The_Evaluator_primitive_domain_types, 

The_Speciric_Software_Characteristic_priniitive_domain_types; 

Package  linkES_Composite_OPS  is 

Type  linkES_record_type  is  record 

EVALJD:  EVAL_ID_Not_NulI; 

SSCJD;  SSC_ID_Not_Null; 
end  record; 


--insert  operations 
"implemented  by  insert  values 

Procedure  insert_LinkES_record(linkES_record:  linkES_record_.type ); 

"Update  operations 
"implemented  by  searched  update 

Procedure  update_Eval_ID(linkES_record:  linkES_rccord_type ; 

with_this_EVAL_ID:  EVAL_lD_Not_Null; 
not_found:  out  boolean); 

Procedure  update_SSC_lD(linkES_record;  linkES_record_typc ; 

with_this_SSCJD:  SSCJD_Not_Null; 
not_found:  out  b(X)lean); 


-search  operation 

"implemented  by  select, fetch,  check 

Function  search_linkES_record(linkESjccord;  rmkES_rcc()rd_typc ) 

return  boolean; 
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"delete  operations 
"implemented  by  searched  delete 

Procedure  delete_linlcES_record(linkES_record:  link:ES_record_type; 

is_deleted:  out  boolean); 

-retrieve  operations 
"implemented  by  cursor/select 

Package  get_ssc_ids^.for_evaLID  is 

Procedure  Open(for_this_EVAL_ID:  EVAL_ID_Not_Null); 
Procedure  Fetch(this_SSC_ID_record:  in  out  linkES_record_type, 
is_fetched:  out  boolean); 

Procedure  close; 
end  get_sscJds_for_eval_ID ; 

Package  get_eval_ids_for_ssc_id  is 

Procedure  Open(for_this_SSC_ID:  SSC_ID_Not_Null); 

Procedure  Fetch(this_EVAL_ID_record:  in  out  linkES_record_type, 
is_fetched:  out  boolean); 

Procedure  close; 
end  get_eval_ids_for_ssc_id; 


end  linkES_Composite_OPS; 
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Package  The_Quality_Composite_OPS 


with  SQL_Base_Types_Pkg, 

The_QuaIity_primitive_domain_types; 

use  SQL_Base_Typcs_Pkg, 

The_Quality_primitive_clomain_types; 

Package  The_Quality_Composite_OPS  is 

Type  Quality_record_type  is  record 

QUAL_1D:  QUAL_ID_Not_Null; 

QUALITY_NAME:  QUALITY_NAME_Not_Null; 

QUAL1TY_VALUE;  QUALITY_VALUE_Not_Null; 
end  record; 

"insert  operations 
"implemented  by  insert  values 

Procedure  insert_Quality_record(Quality_record:  Quality _record_type ); 

"Update  operations 
"implemented  by  searched  update 

Procedure  update_QUALJD(tor_this_QUAL_ID:QUAL_ID_Not_Null; 

with_this_Quality_Id:  QUAL_ID_NolNu11; 
not_found:  out  boolean); 

Procedure  updatc_QUALlTY_NAME(for_this_QUALJD:QUAL  ID  Not  Null; 

with_this_QUALlTY_NAME: 
QUALITY_NAME_Not_Null; 
notjbund:  out  b(X)lean); 

Procedure  updaie_QUALlTY_VALUE 

(for_this_QUALJD:QUALJD_Not_Null; 
with_this_QUALITY_VALUE: 
QUALlTY_VALUE_Not_Null; 
not_found:  out  boolean); 
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-search  operation 

-implemented  by  select, fetch,  check 

Function  search_Quality_record(for_this_QUAL_ID:QUAL_lD_Not_Null; 

return  boolean; 


-delete  operations 
-implemented  by  searched  delete 

Procedure  delete_Quality_record(Quality_record:  Qualityjecordjype 

is_deleted:  out  boolean); 

-retrieve  operations 

Function  UniquelD  return  QUAL_ID_Not_Null; 

-implemented  by  selcct/cursor  select 

Procedure  Quality _record_for_ID(for_this_QUAL_lD;QUAL_ID_Mot_Null; 

this_Quality_re'-ord: 
in  out  Quality_record_type, 
exists:  out  boolean); 


end  The_Quality_Composite_OPS; 
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Package  linkQS_Composite_OPS 


with  SQL_Base_Types_Pkg, 

The_Quality_primitive_domain_types, 

The_Specific_Software_Characteristic_primitive_domain_types; 

use  SQL_Base_Types_Pkg, 

The_Quality_priniitive_domain_types, 

The_Specific_Software_Characteristic_priniitive_doniain_types; 

Package  linkQS_Composite_OPS  is 

Type  linkQS_record_type  is  record 

QUALJD:  QUAL  lD_Not_Null; 

SSCJD:  SSC_ID_Not_Null; 
end  record; 


-insen  operations 
-implemented  by  insert  values 

Procedure  insert_LinkQS_record(linkQS_record:  linkQS_record_type ); 

-update  operations 
-implemented  by  searched  update 

Procedure  update_QUAL_ID(for  this_QUAL  ID:  QUALJD_Not_Null; 

with_this_QUAL_ID:  QUALJD_Not_Null; 
not_found:  out  boolean); 

Procedure  updatc_SSC_ID(for_this_QUAL_ID:  QUAL_ID_Not_Null; 

with_this_SSC_ID:  SSC_ID_Not_Null; 
notjbund:  out  b(X)lcan); 
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-search  operation 

-implemented  by  select, fetch,  check 

Function  searchJinkQS_record(linkQS_record:  linkQS_record_typc ) 

return  boolean; 

-delete  operations 
-implemented  by  searched  delete 

Procedure  delete_linkQS_rccord(for_this_QUAL_ID:  QUAL_ID_Not_NuIl; 

is_deleted:  boolean); 

-retrieve  operations 
-implemented  by  cursor/select 

Package  get_SSC_IDs_for_QUAL_ID  is 

Procedure  Open(for_this_QUAL_ID:  QUAL_ID_Not_Null); 
Procedure  FetchOhis_SSC_ID_record:  in  out  linkQS_rccord_type, 
is_fctched:  out  boolean); 

Procedure  close; 

end  get_SSC_IDs_for_QUALJD ; 

Package  get_QUAL_IDs_for_SSC_ID  is 

Procedure  Open(for_this_SSC_ID:  SSC_ID_Not_Null); 

Procedure  Fetch(this_QUAL_ID_record:  in  out  linkQS_record_typc, 
is_fetched:  out  boolean); 

Procedure  close; 

end  get_QUAL_IDs_for_SSC_ID ; 


end  linkQS_Composite_OPS; 
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Package  The_Specific_Software_Characteristic_Composite_OPS 


with  SQL_Base_Types_Pkg, 

The_Specific_Software_Characteristic_primitive_domain_types, 

General_Software_Characteristic_primitive_domain_types, 

The_Tool_primitive_doniain_typcs; 

use  SQL_Base_Types_Pkg, 

The_Specific_Software_Characteristic_primitivc_domain_types 

General_Software_Characteristic_primitivc_domain_types, 

The_T(X)l_primitive_domain_typcs; 

Package  The_Specific_Software_Characteristic_Composite_OPS  is 

Type  SSC_record_type  is  record 

TOOLJD:  TOOL_ID_Not_NulI; 

GSC_ID:  GSC_ID_Not_Null; 

SSC_ID:  SSCJD_Not_Null; 
value:  value_Type; 
tep:  tep_Type 
end  record; 

-insert  operations 
"implemented  by  insert  values 

Procedure  insert_  SSC_rccord(SSC„rccord:  SSC_record_type ); 

-update  operations 
"implemented  by  searched  update 

Procedure  update_Tool_lD(for_ihis_SSC_lD:SSC_lD_Not_Null; 

with_this_TooLld:TOOL_lD_Not_Null: 
notjound:  out  boolean); 

Procedure  update_GSC_ID(for_this_SSC_lD;SSC_lD_Not_NuIl; 

with_this_GSC_lD:  GSC_lD_Not_Null; 
not_found:  out  boolean); 

Procedure  updatc_SSC_lD(Torjhis_SSC_lD:SSC_lD_Not_NuII; 

with_ihis_SSC_lD:  SSC_lD_Not_Null; 
notjound:  out  b(K>lcan); 

Procedure  updatc_valuc(forjhis_SSC_lD:SSCJD_Noi_Nuil; 

wiihjhis_valuc:  vaIiic_Typc ; 
not_tound:  out  b(x>lcan); 

Procedure  updatejcp(torjhis_SvSC_lD:SSC_lD_Not_NuIl; 

withjhisjcp:  tcp_Typc  ; 
notjound:  out  boolean); 


-search  operation 

-implemented  by  sclcctd’ctch,  check 

Function  search_SSC_rccord(SSC_rccord:  SSC_rccord_typc) 

return  b(K)lcan: 


178 


"delete  operatiais 
"implemented  by  searched  delete 

Procedure  delete_SSC_record(for_this_SSC_ID:SSC_ID_Not_Null; 

is_deleted:  out  boolean); 

-retrieve  operations 

Function  UniquelD  return  SSC_ID_Not_Null; 

"implemented  by  cursor/select 

Procedure  SSC_record_forJD(for_this_SSCJD;SSC_ID_Not_Null; 

this_SSC_record:  in  out  SSC_rccord_type, 
exists:  out  boolean) 

Function  UniquelD  return  SSCJD_Not_Null; 


end  The_Specific_Software_Characteristic_Composite_OPS; 
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Package  Weight_Set_Composite_OPS 


with  SQL_Base_Types_Pkg, 

Weight_Set_primitive_domain_types; 

use  SQL_Base_Typcs_Pkg, 

Weight_Sct_primitive_(lontain_types; 

Package  Weight_Set_Composite_OPS  is 

Type  Weight_set_record_typc  is  record 

WEIGHT_SET_NAME:  WEIGHT_SET_NAME_Not_Null; 
default:  default_Type; 
end  record; 

—insert  operations 
-implemented  by  insert  values 

Procedure  insert_Weight_set_record(Weight_set_record:  Wcight_set_record_typc ); 

-update  operations 
-implemented  by  searched  update 

Procedure  update_WEIGHT_SET_NAME 

(for_this_WEIGHT  SET  NAME:  WEIGHT_SET  NAME.Not  Null; 
with_this_WeighLset_Id:  WElGHT_SET_NAME_Not_Null; 
not_found:  out  boolean); 

Procedure  updatc_default 

(for_this_WEIGHT_SET_NAME:  WElGHT_SET_NAME_Not_Null; 
with_this_dcfault:  default_Typc; 
not_found:  out  b(X)lean); 

-search  operation 

-implemented  by  select,fctch,  check 

Function  scarch_Weight_set_rccord 

(Wcight_set_rccord;  Wcight_sct_rccord_typc)  return  b(X)lcan; 
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-delete  operations 
-implemented  by  searched  delete 

Procedure  delete_Weight_set_record 

(Weight_set_record:  Weight_set_record_type 
is_deleted:  out  boolean); 

-retrieve  operations 
-implemented  by  cursor/select 

Procedure  Weight_set_record_for_name 

(for_this_WEIGHT_SET_NAME:  WEIGHT_SET_NAME_Not_Null; 
this_Weight_set_record;  in  out  Weight_set_record_type, 
exists;  out  boolean); 


end  Weight_Set_Composite_OPS; 


Package  Selcction  Set  Composite  OPS 


with  SQL_Base_Types_Pkg, 

Selection_Sct_primitive_domain_types; 

use  SQL_Base_Types_Pkg, 

Selection_Set_primitive_domain_types; 

Package  Selection_Set_Composite_OPS  is 

Type  Selection_Set_record_type  is  record 

SET_NAME:  SET_NAME_Not_Null; 
end  record; 

-insert  operations 
“implemented  by  insert  values 

Procedure  insert_Sclection_Set_record(Selection_Set_record: 

Selcction_Sct_record_type ); 


-update  operations 
-implemented  by  searched  update 

Procedure  updatc_SET_NAME(Selcction_Set_record; 

Selection_Sct_rccord_typc; 
with_this  Selection  Set  Name; 
SET_NAME_Not_Null; 
not_found:  out  boolean); 

-search  operation 

“implemented  by  select,fetch,  check 

Function  search_Sclcction_Sct_rccord(Sclcciion_Sct_rccord: 

Sclcction_Sct_rccord_typc)  return  boolean; 


IS2 


--delete  operations 
-implemented  by  searched  delete 

Procedure  delete_Selection_SeLrecord(Selection_Set_record: 

Selection_Set_rccord_type 
is_deleted:  out  boolean); 

-retrieve  operations 
-implemented  by  cursor/select 

Procedure  Selection_Set_record_for_name 

(for_this_SET_NAME:  SET_NAME_Not_Null; 
this_Selection_Set_record: 
in  out  Selection_Set_record_type, 
exists:  out  boolean); 

end  Selection_Set_Composite_OPS; 
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Package  linkSAWT_Composite_OPS 


with  SQL_Base_Types_Pkg, 

Selection_Set_primitive_doniain_types, 

Weight_Set_primitive_doniain_types, 

The_Tool_primitive_domain_types, 

The_Area_primitive_domain_types; 

use  SQL_Base_Types_Pkg, 

Selection_Set_primitive_domain_types, 

Weight_Set_primitive_domain_types, 

The_Tool_primitive_domain_types, 

The_Area_primitive_domain_types; 

Package  linkSAWT_Composite_OPS  is 

Type  linkSAWT_record_type  is  record 

SET_NAME:  SET_NAME_Not_Null; 

AREAJD:  AREAJD_Not_Null; 

TOOL_ID:  TOOL_ID_Not_NulI; 

WEIGHT_SET_NAME:  WEIGHT_SET_NAME_Not_NuIl; 
end  record; 


--insert  operations 
-implemented  by  insert  values 

Procedure  insert_LinkSAWT_rccord 

(linkSAWT_record:  linkSAWT_record_typc ); 

-update  operations 
-implemented  by  searched  update 

Procedure  SET_NAME(linkSAWT_record:  linkSAWT_record_typc ; 

with_this_SET_NAME:  SET_NAME_Not_NulI; 
not_found:  out  boolean); 

Procedure  update_Area(linkSAWT_record:  linkSAWT_rccord_type ; 

with_this_AREA_ID:  AREA_ID_Not_Null; 
not_found:  out  boolean); 

Procedure  update_Tool(linkSAWT_record;  linkSAWT_record_type ; 

withJhis_TOOL_lD:TOOL_ID_NoLNull; 
not_found:  out  b(X)lcan); 

Procedure  update_WElGHT_SET_NAME 

(linkSAWT_rccord:  linkSAWT_record_type ; 
with_this_WEIGHT_SET_NAME: 
WEIGHT_SET_NAME_Not_Null; 
notjbund:  out  b{X)lcan); 


-search  operation 

"implemented  by  select, fetch,  check 
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Function  search_linkSAWT_record(IinkSAWT_record:  linkSAWT_record_type ) 

return  boolean; 


-delete  operations 
“implemented  by  searched  delete 

Procedure  delete_linkSAWT_record(linkSAWT_record:  linkSAWT_record_type; 

is_deleted:  out  boolean); 

-retrieve  operations 
“implemented  by  cursor/select 

Package  get_tools_for_SET_NAME  is 

Procedure  Open(for_this_SET_NAME;  SET_NAME_Not_Null); 
Procedure  Fetch(linkSAWT_record:  in  out  linkSAWT_record_type, 
is_fetched:  out  boolean); 

Procedure  close; 

end  get_tools_for_SET_NAME ; 

Package  get_SET_NAMES_for_tool  is 

Procedure  Open(for_this_TOOL_ID:  TOOL_ID_Not_Null); 

Procedure  Fetch(linkSAWT_record;  in  out  linkSAWT_record_type„ 
is_fetched:  out  boolean); 

Procedure  close; 

end  get_SET_NAMES_forjool; 
end  linkSAWT_Composite_OPS; 
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Package  software_char_score_Composite_OPS 


with  SQL_Base_Types_Pkg, 

software_char_score_primitive_domain_types, 

Weight_Set_primitive_doinain_types, 

The_Specific_Software_Characteristic_primitive_domain_types; 

use  SQL_Base_Types_Pkg, 

softwarc_char_score_primitive_domain_types, 

Weight_Set_primitive_domain_types, 

The_Speciric_Software_Characteristic_primitive_domain_types; 

Package  software_char_score_Composite_OPS  is 

Type  software_char_score_record_type  is  record 
SSC_ID:  SSC_ID_Not_NuiI; 

WEIGHT_SET_NAME:  WEIGHT_SET_NAME_Not_Null; 
function_score:  function_score_Type; 
quality_score:  quality  _score_Type; 
end  record; 


--insen  operations 
“implemented  by  insert  values 

Procedure  insert_software_char_score_record 

(software_char_score_record;  software„char_score_record_type ); 
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-update  operations 
-implemented  by  searched  update 
Procedure  SSCJD 

(SSC  JD:  SSC_ID_Not_Null; 

WE1GHT_SET_NAME:  WEIGHT_SET_NAME_Not_Null 
with_this„SSCJD:  SSCJD_Not_Null; 
not_found:  out  boolean); 

Procedure  update_function_score 

(SSC.BD:  SSC_ID_Not_Null; 

WEIGHT_SET_NAME:  WEIGHT_SET_NAME_Not_Null 
with_this_function_score:  function_score_Type; 
not_found:  out  boolean); 

Procedure  update_quality_score 

(SSC_ID:  SSC_ID_Not_NuIl; 

WEIGHT_SET_NAME:  WEIGHT_SET_NAME_Not_Null 
with_this_quaiity_score;  quality_score_Type; 
not_found:  out  boolean); 

Procedure  update_WEIGHT_SET_NAME 
(SSC_ID:  SSC  ID_Not_Null; 

WEIGHT_SET_NAME:  WEIGHT_SET_NAME_Not_Null 
with_this_WEIGHT_SET_NAME: 
WEIGHT_SET_NAME_Not_Null; 
not_found:  out  boolean); 


-search  operation 

“implemented  by  select, fetch,  check 

Function  search  software_char_score_record 
(SSC_ID:  SSC_lD_Not_Null; 

WEIGHT_SET_NAME:  WElGHT_SET_NAME_Not_Null) 
return  boolean; 
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"delete  operaticMts 
"implemented  by  searched  delete 

Procedure  delete  software_char_score  record 
(SSC_ID:  SSC_ID_Not_Null; 

WEIGHT_SET_NAME:  WEIGHT_SET_NAME_Not_Null; 
is_deletcd:  out  boolean); 

-retrieve  operations 
"implemented  by  select/cursor  select 
Procedure  get_s,cores 

(SSC.ED:  SSC_lD_Not_Null; 

WEIGHT_SET_NAME:  WElGHT_SET_NAME_Not_Null; 

software_char_SLore_record: 

in  out  software_char_score_record_type; 

is„fetched;  out  boolean); 


endsoftware_char_score_Composiie_OPS; 
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Package  tool  score  Composite  OPS 


with  SQL_Base_Types_Pkg, 

tool_score_primitive_domain_types, 

The_TooLprimitive_domain_ty^s, 

Weight_Set_primitive_doniain_types, 

General_Software_Characteristic_primitive_domain_types; 

use  SQL_Base_Types_Pkg, 

tool_score_primitive_domain_types, 

The_Tool_primitive_domain_types, 

Weight_Set_priniitive_domain_types, 

General_Softwarc_Characteristic_primitive_domain_types; 

Package  tooLscore_Composite_OPS  is 

Type  t(X)l_score_record_type  is  record 
GSCJD:  GSC_ID_Not_NulI; 

TOOLJD:  TOOL_ID_Not_Null; 

WEIGHT_SET_NAME:  WEIGHT_SET_NAME_Not_Null; 
function_score;  function_score_Type; 
quality_score:  quality_score_Type; 
end  record; 


--insert  operations 
-implemented  by  insert  values 

Procedure  insert_ioo!.  scorc_record 

(t(X)i_score_record:  tooLscore_record_type ); 
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-update  operations 
"implemented  by  searched  update 

Procedure  update_GSC_ID(  GSC_ID:  GSC_lD_Noi_Null; 

TOOL_ID;  TOOL_ID_Not_Null; 
WEJGHT_SET_NAME: 
WEIGHT_SET_NAME_Not_Nun; 
withJhis.GSGJD:  GSC_lD_Not_Null; 
not_found:  out  boolean); 

Procedure  update_TOOL  ID(GSC_ID:  GSC_ID_Not_Null; 

TOOLJD;  TOOL_ID_Not_Null; 
WEIGHT_SET_NAME; 
WEIGHT_SET_NAME_Not_Null; 
with_this_TOOL_ID:TOOLJD_Not_Null; 
not_found;  out  boolean); 

Procedure  update_function_score 

(GSCJD:  GSCJD_Not_Null; 

TOOLJD:  TOOL_ID_Not_Null; 

WEIGHT_SET_MAME: 
WEIGHT_SET_NAME_Nor_Null; 
withjhis_function_scoro:  function_score_Typc; 
notjound:  out  boolean); 

Procedure  update_quality  score 

(GSCJD:  GSCJD.Not.Null; 

TOOLJD:  TOOL  ID  Not_Null; 

WEIGHT_SET_NAME: 
WEIGHT_SET_NAME_Not_Mijll; 
with_this_qualiiy_score:  quality_score_Type; 
notjound:  out  boolean); 

Procedure  updatc_WHIGHT_SET_NAME 
(GSC_ID;  GSCJD_NolNu11; 

TOOL.ID:  TOOL_ID_Not_Null; 

WEIGHT_SET_NAME: 
WEIGHT_SET_NAME_Not_Null; 
\vithjhis_WEIGHT_SET  NAME: 
WFIGHT_SET_NAME_Not_Null; 

•’.ot  Jound:  out  boolean); 


-search  operatk 

-implemented  by  sclcci,fetch,  check 

Function  scarch_tool_scorc_rccord 

(t(X)Lscorc_rccord:  t(X)ljscorc_rcc()rd_iy|jc) 
return  boolean; 


-delete  operations 
-implemented  by  searched  delete 
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Procedure  deIetejool_score_record 
(GSC_ID:  GSCJD_Not_Null; 
TOOLJD:  TOOL_ID_Not_Null; 
WEIGHT_SET_NAME: 
WEIGHT_SET_NAME_Not_Null; 
is_deleted:  out  boolean); 

-retrieve  operations 
-implemented  by  select/cursor  select 
Procedure  get_scores 

(GSCJD:  GSC_ID_Not_Null; 
TOOLJD:  TOOL_ID_Not_Null; 
WEIGHT_SET_NAME: 

WEIGI  IT_SET_NAME_Not_Null; 
tool_score_record: 
in  out  tool_score_record jype; 
isjetched:  out  boolean); 


end  t(>3l_scOTe_Composite_OPS; 
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Package  software_char_weight_Composite_OPS 


with  SQL_Base_Types_Pkg, 

software_char_weight_primitive_domain_types, 

General_Software_Characteristic_primitive_domain_types 

Weight_Set_primitive_domain_ty^s; 

use  SQL_Base_Typcs_Pkg, 

software_char_weight_primitive_domain_types, 

General_Software_Characteristic_primitive_domain_types 

Weight_SeLpriinitive_domain_ty^s; 

Package  software_char_weight_Composite_OPS  is 

Type  software_char_weight_record_type  is  record 
GSCJD:  GSC_ID_Not_Null; 

WEIGHT_SET_NAME:  WEIGHT_SET_NAME_Not_Null; 
function_weight:function_weight_Type; 
quality_weight:  quality_weight_Type; 
end  record; 


-insen  operations 
-implemented  by  insert  values 

Procedure  insert_softwa!ie_char_weight_record 

(software_char_weight_record:  software_char_weighLrccord_type ); 

-update  operations 
"implemented  by  searched  update 
Procedure  GSCJD 

(GSC_ID:  GSCJD_Not_Null; 

WEIGHT_SET_NAME:  WEIGHT_SET_NAME_Noi_Null; 
with_this_GSCJD:  GSC_ID_Not_Null; 
outjound:  out  boolean); 

Procedure  updatc_functi(Mi_weight 
(GSCJD:  GSCJD_Not_Null; 

WEIGHT_SET_NAME:  WEIGHT_SET_NAME_Not_Null; 
with_thisJunction_weight:  function_wcight_Typc; 
not  Jound:  out  boolean); 
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Procedure  update_quality_weight 

(GSCJD:  GSCJD_Not_Null; 

WEIGHT_SET_NAME:  WEIGHT_SET_NAME_Not_N'’  U; 
with_this_quality_weight:  quality_weight_Type; 
not_found:  out  l^Iean); 

Procedure  update_WEIGHT_SET_NAME 
(GSCJD:  GSCJD_Not_Null; 

WEIGHT_SET_NAME:  WEIGHT_SET_NAME_Not_Null; 
with_this_WEIGHT_SET_NAME: 
WEIGHT_SET_NAME_Not_Nun; 
notjound;  out  boolean); 


-search  operation 

-implemented  by  select.fetch,  check 

Function  search_software_char_wcight_record 
(GSC_ID:  GSCJD_Not_Null; 

WEIGHT_SET_NAME:  WEIGHT_SET_NAME_Not_Null) 
return  boolean; 


-delete  operations 
-implemented  by  searched  delete 

Procedure  delete_software_char_weight  record 
(GSC  ID:  GSCJD_Not_Null; 

WEIGHT_SET_NAME:  WEIGHT_SET_NAME_Not_Null; 
is_deleted:  out  boolean); 

-retrieve  operations 
-implemented  by  select/cursor  select 
Procedure  get  weights 

(GSC  ID;  GSCJD_Not_NulI; 

WEIGHT_SET_NAME:  WEIGHT_SET_NAME_Not_Null; 

.software_char_weight_record: 

in  out  software_char_weight_record_type; 

is..fetched:  out  boolean); 
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Package  get_wcighi_Sets_for_GSC_ID  is 

Procedure  Open(GSC_ID:  GSC  JD_Not_Null); 

Procedure  Fetch(software_char_weight_record: 

in  out  software_char_weight_record_type; 
is_fetched:  out  boolean); 

Procedure  close; 

end  get_weighi_Sets_for_GSC_ID; 

Package  get_GSC_IDS_for_Weight_Set  is 
Procethire  Open 

(for_this_Weight_Set:  WEIGHT_SET_NAME: 
WEIGHT_SET_NAME_Not_Null); 

Procedure  Fetch(software_char_weight_record: 

in  out  softwarc_char_weight_record_type; 
is_fetched:  out  boolean); 

Procedure  close; 

end  get_GSC_IDS_for_Weight_Set ; 


endsoftware_cliar_weight_Composite_OPS; 
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